willCode4Beer

Its Just Another Tool – Processes Revisited

I just started rereading Steve McConnell's book Code Complete (yes I know, I need to get the second edition). Its one of these things I do, every few months or so, I go and re-read books in my collection of development practices.

Anyway, very early on, he mentions several things about design and about keeping it in scope. You don't go about building a doghouse the same way you do a skyscraper.

A bigger point comes to mind. We developers treat programming languages and design patterns as tools in the toolbox called our brain. No serious developer only knows one language. We pick the best language and platform for the task at hand. We don't just use one design pattern, we pick the one that best fits the problem. So, why don't we treat our methodologies the same way? What about our development processes?

You don't spend a week planning to build a doghouse. You don't find a doghouse architect. You don't design a doghouse down to the last nail. You sketch it out on a napkin and drive to the hardware store. You finish it in an afternoon. A doghouse doesn't need a big process.
In the same mode of thinking, you don't hire contractors to build an office building from a back of the envelope sketch.

So, with XP, RUP, SCRUM, Waterfall, BUFD, etc.... why does everybody say there can only be one process (that should be used on every project)? Why not evaluate the scope of the project, the clarity of the requirements, the schedule, and the customer; then pick the best process for the project.

To my observation this is the downfall of CMMI. CMMI requires that all projects should be built with the same process. Sure there are means to customize the process but, its still the same beast no matter what.

Another good post about giving sanity to development processes:
Software Development Processes

Update:
Manuel has written a great response mentioning how some tools just plain belong in other fields of use.

posted by willCode4Beer @ 12:27 AM