Four years ago, Facebook changed its famous motto “Move fast and break things” to “Move fast with stable infra” (not quite as catchy?). Most people associate the original motto with disrupting established business models (see e.g. Jonathan Taplin’s book with the same name). Mark Zuckerberg himself, however, hinted that its origins lie in a particular attitude towards software engineering: “As developers, moving quickly was so important, we would even tolerate a few bugs to do it”. As time goes on, this attitude apparently does more harm than good – as even Facebook found out.
“Move fast and break things”, in software engineering, signifies the need to quickly create functionality in the beginning of a product life cycle. It is related to the first agile principle: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Functionality represents direct business value, and the “break things” part of the motto assigns lower priority to work that represents indirect business value, often called ‘enablers’.
Agile principles eight and nine, however, stress the importance of sustainable development and technical excellence, and the ability to “maintain a constant pace indefinitely”. Enablers create and maintain the architectural backbone of a product and safeguard long-term quality. An organization that neglects enablers in favor of functionality builds up technical debt; the longer enablers are postponed, the higher the debt and its impact on productivity and quality. A product or organization in technical debt cannot maintain a constant pace indefinitely.
All of the large organizations I encounter in my daily work are struggling with a burden of technical debt in one way or another. In many cases, the pressure to “move fast” has led to underfunding of enablers like ‘under the hood’ improvements and technical debt reduction. They have moved fast, and now things are broken.
How did we get here?
Discussions with architects, product owners and managers reveal some potential causes for the technical debt burden:
- ‘Regular’ modern business practices: KPIs (Key Performance Indicators) often lead to prioritizing short-term, measurable success over long-term investments.
- Overinflated stakeholder expectations: temporarily postponing enablers (often for good business reasons) leads to a steep growth in business value, delighting stakeholders. Teams then become reluctant to break the news that they cannot maintain this pace, forcing themselves to keep it up and build up more debt.
- Cargo cult: the success of Internet giants prompts organizations to adopt their methods, practices and frameworks without properly considering the differences in culture and business model (and when the methods fail, their proponents call for even more extreme implementations, because “we must have been doing it wrong” of “we were sabotaged by non-believers”).
- Misapplication of specific agile practices, such as:
- WSJF (Weighted Shorted Job First) prioritization (specific to SAFe, the Scaled Agile Framework): due to their size and indirect business value, enablers generally cannot compete with features and functionality in WSJF prioritization. This is why SAFe advises to allocate capacity for enablers separately; ignoring this advice leads to misapplication of WSJF to enablers, and build-up of technical debt.
- MVP (Minimum Viable Product): an initial product with just enough features to satisfy early customers, and to provide feedback for future development. It is in the nature of MVPs to ignore ‘edge cases’ (rarely occurring uses of the product) and some non-functional requirements (NFRs, e.g. limited scalability). However, edge cases and NFRs can have major impact on the architecture. Continuing development based on an MVP without properly considering (or completely rebuilding) the architecture is a misapplication of the MVP practice that leads to build-up of technical debt.
The road ahead
During the panel discussion on the “Death of the Architect” at this year’s SATURN conference, I joked that the world is drowning in a pool of technical debt. That was a bit overdramatic, but nobody can deny that we have a problem. Not only is the technical debt burden draining businesses’ resources away from their ability to innovate, it is also causing real problems in society – that is how dependent we have become on properly working software. Architectures that do not support edge cases can even have significant ethical implications by excluding groups of clients and citizens from (sometimes essential) services (a number of cases like this are documented extensively in the Kafka Brigade’s ‘The Digital Cage’, currently only available in Dutch).
Technical debt causes real economic, societal and ethical problems. It is time we did something about it – starting by addressing the root causes mentioned above. I do not have the illusion that we can easily change the short-term focus in modern business governance practices, but we can certainly be more transparent in managing stakeholder expectations about sustainable development. We can also be smarter in applying agile practices – most of which is making sure we understand the practices and their limitations before we apply them.
Paying more attention to enablers means there will be less capacity for new things – initially, we will slow down. But maybe that’s a good thing. Grady Booch recently tweeted the question “What does software development look like in a post-agile world?” I hope we will slow down and fix things.
So true Elto,
If I may add, there may be more to the potential causes. Let’s draw a parallel to what nature does.
Have you ever wondered how bones can grow? After all, bomes are not living tissue, and still they grow.
That is because our body has two special kinds of cells: osteoblasts and osteoclasts. The first cells synthesize bone and the latter breaks it down. Together they make life as we know it possible.
So my suggestion for another potential cause is that we always try to add “clean up” as a part of new projects, and we fail repeatedly.
The solution to this is to reserve a part of the budget for cleaning up, and more importantly realise that we need people with a different trait: those who get satisfaction from removing technical debt / cleaning up. Those people are rare and should get valued for their ‘enabling’ contribution.
Eltjo, Ron, good discussion.
Another real world example of paying for enablers/technical debt is “free water”: On a terasse, when you “only” ask for a glass of water and they charge you € 2. That is one cent for the water (still expensive), 10 cents for cleaning the glass and the remainder for the enablers: having a place to sit and be served. Customers tend to forget the latter, but when you explain, it is perfectly accepted. So, why not pay for the enablers in IT projects? Rather than building technical debt, one should always include money for enablers from the start, so that customers get used to it. If that doesn’t work, the business case is going to fail anyway, so you better stop the project early.
Another approach that avoids to pay for technical debt is “throw away architecture”. This is often used with start-ups – so not really applicable to the CGI business model – who tend to build a good looking basic function and then sell, either to another company getting rid of the stuff, or to an invester who then furnishes the money to build it again more properly. When that runs, multiple cycles of completely rebuilding can follow, as long as they make enough money. Many applications are not made to last till enternity.