The project programming work is almost done, and the project manager has set a “code freeze” date. As the lead developer, I am assigning tasks so that the project is done by this date. But the date keeps changing. Almost every day, the PM announces a new code freeze date. Sometimes we have more time to develop, and sometimes we have less. It’s random. And so, when asked what type of programming methodology my company uses, I say we are using Chaos Driven Development (CDD). It’s the hot new thing. Test Driven Development is so “last month”.
Now, doing a quick search on Google, I discover there are no web pages out there that discuss Chaos Driven Development. Not one. The entrepreneur in me sees an opportunity! I could take this to the next level, registering http://www.chaosdriven.com/ and creating a web site about this development style. I could write books, Chaos Driven Development For Dummies. And tour the country giving training and holding conferences.
But the problem is, Chaos is already the dominant programming methodology in IT today. Most teams follow this by-the-seat-of-your-pants style. Noone would buy my books, or attend my training, because everyone knows (all too well) how to do it. Chaos is the natural state of things. It requires work to avoid chaos, but anyone can get a project into a chaotic state.
Many developers, when asked what programming methodology they practice, will freely admit it is similar to the Chaos model. When you ask them if that is the best way to do things, most will mention other models – extreme programming, test driven development, agile process, or Microsoft Solutions Framework. So there is a general admission in IT development that “we could do better”.
I had a hard time last week explaining to some friends of mine what the big deal was about Visual Studio Team System. “Come on”, one said, “that's great in theory, but what about the real world?” “Who has time to follow a formal methodology?” said another.
I have been designing and developing software for more than 13 years, and have had the privelege of working for both large and small companies. I have seen both extremes of software development process: from “way too much process” to “no process” (chaos driven). I intuitively know what is right in terms of process.
Many software developers, however, constantly work in the state of “no process” and cannot see the benefit of adding even a little formailty to software development. They think of it as unnecessary overhead. What they don’t understand is, the emerging methodologies of software development are all about improving the quality of software. When I say quality, I mean:
-
Software that ships with fewer overall bugs
-
Software that better meets the needs of users
-
Software that is more effcient at tasks
-
Software that is better designed and architected
What I tried to tell them (unsuccessfully, apparently) was that ultimately it was up to the developer to make good software - that was true before and it is still true now.
For instance, I doubt many would argue that the overall quality of building construction has improved over the last 50 years. In my mind, two things have been primarily responsible for that trend:
-
improved standards, including inspectors to ensure the building meets government standards (building codes); and
-
improved tools and materials, including prefabricated pieces, strong and light steel, and machines to do some of the hardest tasks
Why do some software developers resist the same types of improvements in the software industry? We should be trying to improve our standards (extreme programming, test-driven development, etc.) and improve our tools (NUnit, Visual Studio, source version control, etc.) as well.