Last week, we celebrated the 40th anniversary of software engineering. Between 7 and 11 October 1968, the NATO Science Committee hosted 62 leading academics and professionals of the young computer industry in Garmisch, a beautiful place in Bavaria, Germany, at the foot of the north face of the highest German mountain. During this conference, the term “software engineering” became popular and started its journey through our domain.
Not too long ago, I understood agile development as an oppositional concept to software engineering. I had identified software engineering with the heavy document-driven processes widely in use in the 1980s and 1990s. This is a popular conception; especially one the proponents of traditional methodologies like to support. The term “software engineering” carries the flavor of a sound, professional discipline and connecting it to “capability” models or processes definitely helps in the debate.
So is traditional software engineering really the sound, disciplined approach, while agile is the free-roaming, chaotic (and thus unprofessional) hacker style? I don’t think so. I’d like to take you on a short journey 40 years back in time. Admittedly, I was more concerned about my sandbox at that time than about software development, but the conference reports available today give a good impression of the discussions that took place in Garmisch.
One statement caught my attention at the first reading. Douglas T. Ross, member of the Massachusetts Insititute of Technology (MIT) at that time and inventor of the CAD paradigm, said about the design of software: “The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job” .
Does this sound familiar to you? It is exactly the same reasoning we use today to explain the success of agile projects. The agile seed was already sown 40 years ago, but for some reason the waterfall plants grew faster. They proliferated the industry to an extent that they were identified with the term software engineering. And only a few professionals — mainly from the Smalltalk camp — still cared for the iterative plants and developed them further until they became what we know as agile today.
Agile development uses many elements of traditional software engineering in a much more rigorous way, such as automated testing, version control, and code reviews (at least if you do pair programming). It also celebrates the quality of design.
My conclusion is: rather than being an opposition to software engineering, agile development is an alternative draft of software engineering. It avoids many of the traditional misconceptions, such as “you have to draw your plans first, before you build,” or “building software is like constructing a house.” Instead it adds the focus on business value, like any other mature engineering discipline. It is a full-grown descendant of the early ideas of software engineering.
Agile development may add some new misconceptions we don’t know about yet. Probably we will know 40 years from now, but then most of us will not be concerned about software development too much anymore.