If builders constructed buildings the way programmers write software, the first woodpecker that came along would destroy civilization.
Gerald Weinberg, an early computer science professor and practitioner, may have made this statement mid-1970s (other citations are also quoted). Despite my entire career being spent in technology-related fields, I had not previously heard of this law: don’t know how I missed it.
What is more damning is its continued relevancy fifty years later, that despite improvements in languages, tooling, design patterns, coding paradigms, observability, hardware, networking, and much more, it remains an accepted practice to ship solutions with known errors, incomplete functionality, missing non-functional requirements, security holes. Not only accepted, in fact it’s expected: modern methodologies (Agile in particular) replaces detailed design with short, piecemeal releases that incrementally build up functionality. Many organizations expect (force) engineers to ship early and often, quality be damned, get functionality to consumers now and address short-comings (errors and non-functional requirements) later.
Spoiler #1: later never comes.
Spoiler #2: engineers who push back are sidelined.
Solutions are increasingly larger and more complex, understanding end-to-end use cases is increasingly difficult, errors are insidious to debug, understand and fix, new functionality dependent on understanding the existing. Attempting to explain to leaders falls on deaf ears because it doesn’t fit their narrative. Engineers make the best of a bad situation and hope they don’t have to fall on their sword. And introducing AI into the software supply chain only makes it worse.
As solutions became larger and more complex, understanding end-to-end flow becomes increasingly difficult, problems become more insidious to debug and fix, creating new functionality without breaking existing is borderline impossible. AI’s entering the software supply chain increases the level of difficulty.
Unfortunately, I don’t anticipate any behavioral changes: it’s much easier for leaders to offer mea culpas than spend the time, effort, money up-front, especially since they are often rewarded for functionality not implementation. Very depressing…
