Hairball of Mud
“Things are not difficult to make; what is difficult is putting ourselves in the state of mind to make them.” Constantin Brancusi
We've seen many product development teams, product owners and organisations in trouble because they were blocked by what is called technical debt or legacy code to truly create value for the customer. Who has not heard their teams moaning about that 'hairball of mud', 'technical debt' or 'legacy app' making the 'rebirth' or 'rewrite' unavoidable? This hairball of mud slows everything down, creates high variability and unreliability in creating customer value, and adds to what humans hate the most: uncertainty and not being in control?
If your organisation does have that disease, you may just lack the technical skills to build a solution that fits the problem you are trying to solve with your product but we are pretty sure your culture is having an issue too. What you see in this hairball of mud is the accumulated result of coding, planning to code and all the decision making related to this effort.
The history of successes, compromises, failures, projects, roadmap meetings, design decisions, sprint planning meetings and customer insights manifested in your code base has shaped over the years the core assumptions about how to be successful and what is assumed to be good or bad as values in your organisation. This flow of events has shaped an essential part of your organisational culture: the routines of how to deal with stress and that are emerging in the form of a hairball of mud.
The organisational culture is self-referential and complex since the shared values and core assumptions influence the decision making that creates artefacts which themselves feed back into the system. That's probably bad news since changing a complex adaptive system (CAS) can be quite an overwhelming task and much harder than many people think since:
CAS have their own lives and respond in surprising, non-deterministic ways to changes in their environment.
They can't be understood completely by an agent who is part of the system, and
because of A and B approaching them in a direct, plan-driven way, you have a recipe for failure.
Thus, all of our well-meaning 'rewrite', 'rebirth' and 'greenfield' initiatives which ignore the mindset but address these complex hairball of mud problems on pure technical grounds are fundamentally flawed and have a high chance of making things worse. This rewrite initiative leads to a death spiral for the hairball of mud that is now end-of-life adding to the short-term thinking. This is expressed by “we know this shortcut will only be there for a very short time (like the ones we did December 2008, 2009, 2010 but never found the time to clean things up later)”.This will increase the risk if the rewrite initiative doesn’t work out as hoped since there is no way back. The rewrite is a daunting task itself if it is started under the assumption that the new solution must at least replace the scope of the old one 1:1. If this catch-up race is going on for too long then the old solution may become a moving target and consume a lot of energy and focus - and we know what’s going to happen under extraordinary stress if the cultural operating system’s routines are still in place.
So chances are high that starting a challenge like a rewrite with the same mindset, without having changed the way to make decisions under pressure will not generate the desired results - the rewrite is creating pressure for sure since you have to deal with two technical problems, not just one. The danger coming from technical debt makes avoiding it the first choice. Yet if you run into this problem, there are ways out but they are more painful and risky than normally assumed. Those who managed to replace a broken system with a new one have shared some similarities in their approach:
Use a diversity of perspectives - look at the problem from multiple perspectives, not just technology.
Develop models in collaboration - ask 5 Why to create a shared understanding of the problem and how to approach it by everyone involved, including executives and main stakeholders.
Assume dependence on context - Understand the risk that comes from working on two solutions in parallel and try to avoid the catch-up race.
Shorten the feedback cycle - use small, incremental steps on the whole problem, culture included, experiment, reflect and adapt.
Anticipate, adapt, explore - continuously question and improve the technical capabilities.
Assume subjectivity and coevolution - watch out for unhealthy stressors, create autonomy and options, thus improve your agile planning muscles.
Address complexity with complexity - try to reduce complexity and involve the whole team in finding a solution.
Steal and tweak - don’t throw everything away, learn from what you have and adapt it.
So check your work style: if your cultural operating system’s routines are causing you to make that hairball of mud over and over again, make it visible what’s behind and hack your organizational culture.
References
Links
Let´s help Melly by Jurgen Appelo
Conways Law & Organizational Change by Allan Kelly
Why Can´t We End Short-Termism? by Steve Denning
5 Whys Publication Organizational Culture and Leadership by Edgar H. Schein