From Chapter 1:
Excerpt
The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. (page 9)
Brooks completes his list of "inherent woes" with the inevitable fact of obsolescence. While the developers were heads-down grinding out the software, the competition has hopscotching ahead with new features and the platforms and tools have evolved to the next thing. It's just a fact that software is always out of date the moment it's completed. In the fast moving world of software development, nothing stings the programmer like hearing there's already something better out there and they are working in the past. In closing, Brooks offers a mature (but unsatisfying) managerial perspective: better is better, but the product has got to get out the door and provide "real solutions to real problems."
I have repeatedly experienced this very woe. The temptations are great. There's always a new shiny thing promised by Sun/Oracle, Microsoft, Apple or Wind River. And then there's that great idea the customer wants which could easily be crammed in (maybe without telling management.) Why not just get that in now? The pursuit of perfect software can become a race on a gerbil wheel. At some point a developer will weary and be done with the software, but the software is never done.
Perhaps it will be a surprise to learn that a NASA software engineer is hardly, if ever, plagued by obsolescence. Developing for a mission is a heads down business with little time for the temptations of shiny new things. It's life in a technology bubble. Competition is not a factor--only a need to demonstrate unique requirements. The newest flight software runs on decade old processors (rad-hard design rules) and flight-software design is governed by strict inheritance. For ground systems, maintenance is the watchword since improvements are prohibitively expensive due to brittle, legacy architectures. But, most importantly, there is a conventional wisdom that new is risky. (It's a conventional that deserves scrutiny.) So, if you happen to be a developer working on mission software, there will diminished prospects for meaningful innovation--obsolescence is a fact of life; not a problem.
In the "Aristocracy, Democracy and System Design" chapter, Brooks argues that programming is creative. In fact, programmers will create. That's what they do. So what happens when programmer creativity meets insularity and a risk-averse management? Programmers will create anyway, but in the context of this insular technical milieu. The result: there is a cadre of very talented people busily reinventing technology 5 years behind the curve--innovation on the trailing edge.
As a development manager, I often tried to advance the use of new technologies that would help us build better systems. Most attempts were thwarted for the reasons described. But what troubled me most was that my peers, who shared my frustrations, accepted the status quo as the way things would always be.
Excerpt
ReplyDeleteThe last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. (page 9)
Since what I know about software development could be engraved on an unusually small grain of rice, I must relate to the quote to something more obvious, like the expansion of the 405 project -- years away from completion and it's already obsolete. But I suspect that adding manpower might at least hasten its achievement of functional obsolescence. Sounds, from what you've written so far, like fear(or "risk-aversion," as you describe it) is the biggest obstacle to innovation at NASA. It would interesting to hear comments from software engineers at SpaceX and other contractors.
What I know about the engineering challenges of highway construction would fit on the same rice grain, but it would seem that the 405 expansion could be sped up with more manpower. For example, after the '93 Northridge quake, the I-10 repair was completed in just a couple of months. Maybe someone out there can shed some light.
DeleteHowever, I think you touch on a key question. If you could speed things up for the 405 expansion, why can't you speed up a software engineering task (even if only to make less obsolete)? Brooks devotes most of chapter 2 to the subject.
I have a deeper question in mind. Is software engineering fundamentally different that other engineering disciplines? More generally, should software be approached using the same types of methods used in traditional engineering disciplines? Would the state of affairs improve if only the same methods and remedies were applied?
I've heard aerospace engineers, electrical engineers, and mechanical engineers (the people who build different parts of a spacecraft) joke-on-the-real that, unlike programmers, they are 'real' engineers. Interestingly, there's a long standing debate whether computer science is really a science. After all, programmers don't deal with physical things with real properties that can be characterized in a predicable mathematical way.
In my view software engineering is different. In later postings, I'll argue that the management failure to recognize this differences is a root cause of many of the software development woes.