Functional decomposition is the root of all evil

In SE Radio Episode 407 Juval Löwy made some bold statements. So I got curious, read the first part of his book Righting Software, and will publish the aspects I found most interesting. This is the first of a series of articles about his ideas and some reflections of mine.

His first major thesis is that functional decomposition is the mother of all software maintainability issues. A position backed by the Software Engineering Institute. The reasoning is that - by tightly coupling the structure to requirements - future requirement changes inevitably require structural changes.

Indeed in classical project management the goal is to finish the development project. But even if the project completes in time, in budget, and with the expected functional scope, maintainability tends to be an afterthought. Which, according to Software Engineering at Google would be mere software development, but not software engineering. Because "software engineering is software development integrated over time." ([WMW2020])

Agile approaches focus on delivering value early and often. Still, maintainability is not guaranteed to be a concern. The Nature of Software Development suggests that for each increment the software should be well-designed (see Quintessence of (agile) software development), but that’s quite hand-wavy.

In A Software Quality Model I suggested to link concrete quality attributes of the software system to "fitness for change". But this still doesn’t answer how to decompose your software. Curious about the solution suggested by Juwal Löwy? Read on.