There’s an essay I read awhile ago by David Foster Wallace called Tense Present. It’s a bit verbose (as is his wont), but it’s quite worth the read. The essay is nominally about dictionaries and the English language, but it’s really about two types of people, each with their own ideology. There are the descriptivists and the prescriptivists. Put shortly, the descriptivists wish to have definitions describe common usage. Conversely, the prescriptivists wish to determine correct definitions and prescribe their usage.
So how on earth does this relate to software development? Well, when you ask someone about what a software development process is, you’re likely to get two kinds of answers:
- A prescription for how a dysfunctional software development team should work
- A description of the way that efficient software development teams work
If you examine the major schools of software development methodology, you’ll see that many of them cleanly fit into one of the two camps. Waterfall is the Ur-Methodology for prescriptivism. Starting as early as 1956, Waterfall attempted to reign in the unpredictability of developing digital systems. Its pitfalls are well-known, so I’ll leave it there as a historical accident. In the early 2000s however, the Agile methodology came to take the software development world by storm. On its surface, the Agile process was everything that Waterfall wasn’t- it was flexible, developer friendly and tolerant of failure. However, the ideological underpinnings of Agile are the same as Waterfall. They’re both members of the prescriptivist ideology of software development.
Waterfall and Agile alike take the view that a software development organization is inherently flawed. Software development is messy. Unruly. Unpredictable. Inefficient. The adjective is relatively unimportant. What is important is that each methodology prescribes a solution to these perceived problems. They are born of the fundamental conceit that software development, outside of an enforced process, is broken. In the past decade, perhaps unconsciously, developers have begun to reject this assertion and move to the other camp’s ideology.
The descriptivist ideology of software development has two major methodologies: Extreme Programming and Kanban. Both are born out of observing well-functioning organizations and providing recommendations based on experience. Extreme Programming maximizes flexibility and communication. Kanban maximizes independence and visibility. However, each is still part of an ideology: they are belief in a better way without any concrete evidence to back up that belief. They have goals and methods, just like any other ideology. Nobody has hard facts on what software development processes actually work. The best the descriptivist camp has is “Well, this worked for me,” and the discussions around it follow that same pattern.
I already am eating from the trash can all the time. The name of this trash can is ideology. The material force of ideology makes me not see what I am effectively eating.
I’m going to steer clear of any recommendations here. That’s not what this is about. This is getting you to put on the sunglasses and view things for what they really are. Whenever someone advocates for a software development process, they’re advocating for an ideology as well. There are no real facts here. There’s no science to prove it will work. It’s belief. Treat it as such.
Thanks, Erik Peterson
To discuss, @ me.