In today’s blog post we will start to look into another common symptom; “We get slower and slower for every feature we are adding”. This feeling is a very common feeling in software development organisations.
Asking why on “We get slower and slower for every feature we are adding” gives this symptom.
- “We have a crappy systemisation”, something that Mary Poppendieck has pointed out during many years. And the difference between hardware and software product developent is obvious, since in hardware a crappy systemisation is visible for the customer, but in software it is invisible.
But once again it depends a lot of what kind of software it is; a) If it is software situated on a hardware consumer product, that has a very fast life cycle, like a mobile telephone, the need of the perfect architecture is lower, but also depends on the ability to reuse the software on the coming hardware. b) A software situated on a hardware platform that will live for decades, with a continuous release of new hardware modules, definitely needs a good architecture alreday from start. Otherwise the risk is high for a crappy systemization over time, which will make the implementation time longer and longer for every new software release, until it is not possible to make any new releases.
There always need to be a balance on how long time we need to prepare the architecture. The longer we are working with the perfect architecture, the longer the customer need to wait because we are not coding. But, if we are too sloppy with the architecture the customer will wait for later releases, and we will waste our time on spaghetti code, which is also very difficult to maintain. And when doing a transformation of the way of working to a software framework, we need to be careful about the latter. The reason is that the framework implementation road map for sure will propose the “we make the architecture when we need it” or we prepare the architecture before we transform, since then the transformation will look more successful than it really is. A too well paved road, very far from reality.
So, asking why again, give us one of our root causes; “We do not have control and responsibility over the system product’s architecture”.
A part of the Prefilled Problem Picture Analysis Map with the chain of symptoms for “We get slower and slower for every feature we are adding” will then look like this:
This was all for this blog post, and in the next blog post in this series we continue with the next symptom, “Hidden faults/low quality are discovered too late”. C u then.