Old-School development methodologies

The Software Development industry is in it's adolescence

The software industry is fairly young, the first Personal Computer together with the Operating System that made it wide-spread (MSDOS) was only available in 1981 [1].

Since then the industry has evolved very, very fast which allowed many "snake oil" sales men to take it over (I could name a few...). The explosive growth also allowed many people with low or no technical qualifications to enter the industry, including at the top-management level.

Without enough time to sediment learning and with a drive for quick-(empty)-profit (remember the IPO's of the late 90's?) the industry was then invaded by a horde of fresh MBA's that had no knowledge of what software development really is.

This, of course, led to a lot of failed companies a lot of grieving, but it also opened the doors for those in the industry that did understand the software development process.

People like the ones behind the Agile Manifesto (www.agilemanifesto.org) started making waves in the software development industry due to their success in leading and participating in software development projects.

Surely enough a huge discussion ensued about what is the "best" software development methodology (even within the Agile Manifesto original signatories). As luck would have it we humans learn better by analogy, so a war of analogies was inevitable. We heard of software development as house building (remember waterfall), as a "cooperative game of invention and communication" [Cockburn], we've also heard that waterfall is a bit like the famous middle-age practice of "blood-letting" [Larman]. Here's one more: software development is like making an animated movie.

Analogies are only useful if they allow us to gain some insight into the object of our study (software development in my case). Movie-making offers some important insights in the software development process, but I shall discuss those in another post, as this one is quickly becoming too large :)

Why, then do I use the "old-school" qualification?

Old-School software development methodologies are based on "old principles" that, even though they worked at some point (before we knew better) they are clearly outdated and are no longer effective.

Old-school software development methodologies are based on old organizational structures which follow heavily the pyramid organization of the Old Church (Catholic Church) and pre-Enlightenment days. The pyramidal organizations also follow closely the "command-and-control" principle, that's the basis behind the successful implementation of a Pyramidal organization.

Old-school software development methodologies tend to be taught in schools in the same way as education happened in pre-Enlightenment days: heavily based on theory, book reading and remembering, instead of practice and empirical analysis or real cases. This leads the students to believe in a system of values without ever understanding them or it's application deeply.

Old-school software development methodologies tend to rely on the old idea of scientific management [Taylor in Semler] in which someone can tell a developer how best to their job without actually doing it. Example: a Software Architect/Software Designer telling a programmer how the code should be written, even when they don't touch the code! To improve results with this technique try having the Software Architect in the United States and the Programmer in India :) (I don't mean with this that we don't need Software Architects, they are fundamental and their role will be discussed in another article)

Old-school software development methodologies follow the old Ford model of industrial production, as if programming could be equated with an assembly line. A basic problem with this approach is that not even cars are produced the same way anymore [Poppendieck]... Why should software? To best visualize what is meant by this paragraph please re-watch the Chaplin classic "Modern Times".

Old-school software development methodologies are also based on old management methods. These management methods advocate control by stating that no one in the lower ranks of the pyramid is really competent (otherwise they would be managers) so the top management must control the lower ranks with tight and rigid rules designed to make those in the lower layers more productive than they could be were they to be given freedom to organize their own work (God forbid).

So what methodologies am I referring to?

As you can easily understand I'm referring to all methodologies that, like waterfall, follow the set of values described above.

All methodologies follow a set of values that define them and how they will be understood and applied. I use the term "Old-school software development methodologies" to easily label all methodologies that are based on the set of values described above and in contrast with Agile Software Development Methodologies which follow a different set of values.


Like this post? Let others know: Digg it!

References:
[Cockburn], Alistair Cockburn, Agile Software Development, Addison-Wesley, 2002
[Taylor in Semler], discussion about tailorism in Ricardo Semler, Arrow Books, Maverick!, 1993
[Larman], Craig Larman, Agile and Iterative development, a Manager's guide, Addison Wesley, 2003
[Poppendieck], Mary Poppendieck et al., Lean Software Development: An Agile Toolkit, Addison Wesley, 2003