Shaun MacRae

I saw a tweet recently that read ‘Use of “general” and “flexible” are design meeting smells’.

The truth is, words like “generic”, “general”, and “flexible” are pretty loaded words. Like the words “architect”, and “agile”, these words have different meaning to different people and unfortunately are very often misused.

The word generic is also a very absolute term. So absolute, that it actually never makes sense to use in terms of software, without a relative operator like ‘more’ or ‘less’ to describe the scale of flexibility. To say that a solution is generic is a fallacy because there is no way to assert whether a solution is generic or not. Generic implies a maximum level of abstraction. In absolute terms, this is not achievable. Does the solution cut my grass? Surely it’s not generic then.

I think in many cases the words are used flippantly in work cultures that don’t encourage innovation and evolutionary design. In cultures where software is largely defined up front and defined to satisfy requirements that are not well known or in some cases not known at all, design meetings will be driven by excessive, risk-adverse, use of this language. In work-cultures where software is not largely defined up front, or in worse cases not defined up front at all, the same thing can happen for different reasons. In this case, developers feel like they never have an opportunity to develop great solutions because they are forever putting out fires due to lack of planning. For them, use of these words is almost like a defense mechanism, and they come out of their mouth before they’ve even thought about it. They tend to overcompensate in an effort to manage delivery expectations.

I believe both cases are driven by good intentions. As developers, we like to abstract. Doing so, can remove complexity, and in many cases add heaps of value. In some cases though, it can work against us. If the solution does cut my grass then it’s possible that it isn’t doing what is supposed to do very well. The problem is when we start to look at abstraction as a silver bullet. We must remember that like “architecture” and “agile”, abstraction is a tool. Not unlike the tools we build, it isn’t the only one in the toolbox.