Focusing on the business often has a negative effect on software. More precisely, when implementing a “system”, that is, something on which future functionality will continue to be hung, thinking inside the business domain is too narrow. When writing an application, thinking inside the application domain is too narrow. Whatever it is, imagine writing more than one of them and design it that way.What I mean is that most code is definitively unreusable, because it has been implemented narrowly, based on the current business context. And of course it will be worthless in the future, because the business needs change. Business domain knowledge is necessary for successfully implementing applications and systems. It’s not hard to come by and I’ve rarely seen it missed, because that’s what get tested.
Descending the layers of software, we should be generalizing. This is actually where most of the lines of code should be. If each line of code is an asset, I’d rather have it tied up in general purpose functionality that I get to reuse, not in this application, forever in my sight, but unreachable. As we climb “up” the layers, the code should start to become more domain and then application specific. If we organize this way, new code is new code; you won’t find yourself writing the same code constructs over and over. You won’t have to change every layer in your stack all the time. Most of the work for future functionality is already available
Make use of all the mechanics of your language to minimize the amount of application level code that controls flow, e.g. if, switch, loops. [link to “most code doesn’t do anything”]. The code will reflect the functionality more clearly. Application level is the stuff you end up having to keep adding to. As much as it should directly represent the specific requirements of the application, it should have very little mechanical code.
Cost and frustration can be slashed, including maintenance, enhancement and even training, if we become conscious of having to shift between different degrees of contextual awareness when designing and implementing. Between the immediate application necessities and reusable functionalities. Between the right now and the general, timeless patterns that constitute most of the lines of code in existence.
Don’t let “focusing on the business” excuse one-off implementation.