Cogs Not Machines

What does it really mean to construct or devise a software architecture? If we can't answer that question are we just in the code production business or are we following a plan to build something that is greater than the sum of its parts.

We build software to solve a problem but are we also trying to lay the foundations for the solution to the next problem or are we only working in the here and now where we don't worry about tomorrow until it comes. 

With agile practices we've tried to put less emphasis on up-front architecture and bring people down from the ivory tower, so what do we now mean by developing an architecture.

Integrate to Implement

As a software development team we are ultimately tasked with producing something that meets the needs of the user and improves some aspect of their work or play.

However if that is the driver for our architecture then progress from that initial success will require as much effort as the first step we took.

If we construct a monolith of code aimed at solving the problem put in front of us then each subsequent problem will be just as hard to answer.

Implementation should be limited to the cogs that will, via integration, be used to form a problem solving machine. If we achieve this the solution to the next problem may very well require no implementation we instead repeat the integration phase with minor tweaks to the blueprint of the machine.

Re-Use without Re-Compilation

In essence what we are describing is code re-use, but critically this must be achieved without the need for re-compilation.

Some are happy that re-use can be achieved by copy and paste.

What is actually being achieved by this operation is re-use of thought, not re-use of code.

Whoever is copying and pasting the code is simply not having to expend any grey cells on working out a solution to whatever problem they have, the code itself is being duplicated and re-compiled.

If we construct our code into re-useable units, whether we call them libraries, packages or frameworks, we achieve re-use of both thought and code without the need for re-compilation.

We have created a situation where we can build many machines from the same cogs.

Re-Configuration without Re-Compilation

We may construct a piece of code that successfully consumes an API or integrates with a sub-system and this leads us to conclude that we can know integrate with any such system by simply re-configuring the code to a different end-point or URL.

But its important that if this re-configuration is achieved by changing the code then actually what we are producing is slightly modified software not re-using what we already had, this process would have to be repeated multiple times.

Once again re-compilation is not what we want to be doing, all good developers have a healthy laziness that means they'd rather be able to ship exactly what they shipped last time then go to the effort of producing more, slightly modified, software. 

So to go back to our original question, constructing a software architecture is to increase the opportunity for the re-use of effort, thought and code without modification or change.

It should be based on a lethargy that makes us reluctant to want to hit the build button and instead want to point you at the package we've already produced that fits the bill.