The Rise and Fall of Software Recipes

Anbieter zum Thema

Two dreadful trends in IT: Platitudes and metaphors

“Platitudes are pre-munched statements, so obvious and so trivial, that the opposite statement simply makes no logical sense, like “Quality is important” or “Software is ubiquitous”. Such platitudes are used mechanically, as substitutes for reflection or true opinions one can evaluate and possibly consider contradicting. So mechanically in fact, that one no longer questions these platitudes, even when they make no sense whatsoever.

Metaphors are intrinsic to what we are. Recognizing patterns is an evolutional trait of human nature. It is thus – literally – natural for us to go for metaphors, reusing names and concepts outside of their original context, at the risk of stretching the reality. And software development is an ideal area for this natural tendency, as it is all about abstractions. When conveying, comparing and exchanging ideas, these abstractions must be given a name. Rather than invent new words all the time, we reuse existing words based on metaphorical similarities of variable accuracy.

…Software architects are not architects. Software systems do not require maintenance in the industrial sense as they don't wear out the way industrial machines do. Bad smells don't smell bad. A plugin is not actually plugged into anything. Cloud computing does not take place in actual clouds, etc.”

Recipes

“Software recipes appear in different shapes and forms, but they all share a common property. They advocate a subdivision of the software development process into separate predefined activities, to be performed by separate roles if not necessarily by separate people, at separate times. They assert that such predefined divisions of labor will yield tangible benefits in terms of quality and productivity.

…Software quality is one of major challenges of modern world, and requires all the bandwidth and attention we can devote to it. My disagreement with software recipes lies in the means to achieve quality. The overwhelming evidence shows that the process has only superficial effect on the quality of the resulting software. Quality must be built into the product, not into the process used to build the product.

Whether a software recipe contributes anything isn't the point. Any activity advocated by recipes can be useful in some adequately chosen context. Any formalized separation in phases can be shown to bring value in some cases. My claim is that when applied systematically as recipes should, they cost incommensurably more than whatever they deliver.

[….] this cost is tangible, with training, tools, time spent in meetings, dedicated head count and more. The intangible part is more pervasive. It comes from the loss of flexibility induced by any formal division of a task into sub-activities, and from the burden of checking for things just because they are on a checklist, without always realizing that they don't raise a flag more than once out of hundreds or thousands of cases.

Recipes make sense in a kitchen, where one tries to produce and reproduce the same dish as consistently as possible. A systematically mediocre restaurant is always preferred to a less predictable one with huge variations in quality, even if it allows for the occasional sparkle of genius. It is a domain where consistency of the user experience has a value for its own sake.

…But software is different. Even when people talk about software factories, industrialized development processes and other similarly impressive metaphors, software is not mass produced in the way chocolate chip cookies and Toyotas are. Because intrinsically, organically, every piece of software we build is different from the one that was built before.

It differs functionally. It also differs technically: the environment, the hardware power, the software infrastructure we build on, all these aspects evolve continuously. The software we build today differs from that of the team next door, or from what the same team developed last year.”

(ID:44842486)