Several months ago, I read
Dreaming in Code, the story of a well-funded software project with top-notch people that failed miserably. (Well worth a read in it's own right, that's all I'm going to say about it for now.) One of the assertions made by Scott Rosenberg in the book is that one of the short-comings of software engineering as a whole is that we never learn our own history. That is to say, we're so focused on the latest technologies, the new technologies, the future technologies, that we don't spend enough time in the past, learning form the mistakes that we've already made as a profession.
Jump-shift for a moment to a side comment: it seems in my experience that those I admire most in this industry happen to be those who've been in it long enough to have lived that same history, to have learned from their own mistakes rather that other people's mistakes. Same effect, just a longer gestation period.
So, after reading Dreaming in Code, I decided I'd make an effort to read through some of the "classic works" in software engineering. This, as you can see from the date on my last post, has been a slow process -- I basically read those books when I'm traveling, which happens no more often than every six weeks of so. Fortunately, the work I'm reading now -- Brooks' Mythical Man Month -- was first published in 1975, so I'm free of the tyranny of the urgent; an extra week or six won't make the material any less relevant. (To be pedantic, some of the content was written after the original publishing, such as Brooks' 1986 paper, "No Silver Bullet," which I'll quote from momentarily; all references in this post are from the Addison-Wesley 20th anniversary soft-cover edition of "The Mythical Man Month.")
What strikes me as I read Brooks' work is how little things have changed since 1975. (I use that date, since the relevant thoughts from Brooks are consistent throughout the entire book.)
Oh sure, the technology has changed. We're now using multi-core processors, programming in higher-level languages, rather than assembly code on punch cards. But the human problems faced by Brooks are substantially unchanged in my lifetime. (Coincidentally, I was born the same year Brooks first published his collection of essays.)
And.. the more things change, the more they stay the same. I've known for a long time that many of the advancements in recent processor design haven't been anything of the sort. Those "advancements" have simply been the acquisition of enough technology to implement the ideas that von Neumann proposed in the 1940s. Imagine my surprise when I discovered that the same is true of software engineering, a field that changes daily with the advancement of technology.
Brooks, many of you will be delighted to hear, was a dyed-in-the-wool agilista.
For example, he states: "The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later" (pg. 199).
Okay... nothing earth-shattering there. We all know this (even if we don't always put it into practice for whatever reason.) But Brooks goes on to say: "...the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified... So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designed as part of the system definition" (p. 199).
And I can hear you all out there, groaning, claiming that Brooks' statement could equally be used to justify waterfall. After all, isn't that just one "extensive iteration" after another?
And you'd be right.
But, Brooks isn't done yet. The very next paragraph, he strengthens his argument:
"I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely and correctly the exact requirements of a modern software product before having tries some versions of the product they're specifying.
"Therefore, one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements" (p. 200).
There is no shortage of well-reasoned arguments in a similar vein. Unit testing, working closely with clients, rapid development, short iteration cycles, pair programming... all covered neatly in a book first published 33 years ago. (Keep in mind that the book is a collection of papers, so some of the content is older than that.)
Almost makes it worth taking the time to go back and read the seminal works in the field again, rather than fretting about the latest cool technology, doesn't it?