Move slow and fix things

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”).

Other potential causes are due to 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 (Minimal 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.

Product evolution based on a Minimum Viable Product may require rebuilding the architecture

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.