It’s the passion that makes us lose sight of the danger looming ahead, the trap we’re edging towards thanks to our subjective assumptions and vague speculation, the trap of building a over-designed and over-complicated system for its own sake. # *
Most of what we develop is very complex yet at the same time it is just glorified text processing and arithmetics.
Complexity in software has two roots. One is the inherent complexity of our surroundings. It is amplified by the need of software to work on the assumption that something is either true or false, where in the physical world this black or white decision is not always possible. The other is bit esoteric: the acquired complexity we think we need in order to model the undecided physical world in binary. We usually are not in a position to understand the full scope of what we are working on. We assume and estimate, but we do not know. When we are done, we do have a pretty good idea of what we did, but we still do not know whether we actually are done. We also do not know for sure all the flexibility we built into it is ever going to be needed to the extend we thought it would (acquired complexity).
There are many ways to tackle complexity, to break it down and make the goal achievable. Along the way decisions need to be made based on our understanding of the problem at that time. While at the time something sounded like a good idea, it might turn out we have piled up technical debt. We are then forced to pay back the debt by refactoring our code so that it reflects our up-to-date, most of the time much better understanding of the problem.
The question Maxim rises in his article CMS Trap (quoted at the top) is, on first glance, how to speed up the clearing of technical debt or avoid accumulating too much of it in the first place. His context is a special one, aiming at early stages in the development of a website for a start-up. But let us leave this aside for now.
Flexibility is the ability of a system to change its behavior. The quicker it can do that, the more flexible it is. While some behaviors can be easily changed, others require much more thought, thus adding complexity. Talking about something that spits out structured markup, displaying a different data point anywhere in a template is not hard. Truncating it by an arbitrary value chosen by an editor needs much more work.
There are two assumptions here. First, that there is an editor next to the developer. Second, that this editor needs control of how to display data without involving the developer.
The fundamental question is how to establish whether an assumption is valid enough to justify adding complexity.
Image by Mark Witton, CC-BY-NC-SA.
*) While Maxim’s article might be a good read for some, I think I should mention that I do not share his point of view. Nevertheless, it made me think. So, thank you Maxim :-)
2 comments