Monday, February 19, 2007

The Waterfall Method and Process

Most computer programmers have had to deal with 'process' at some point or another. To some, process is an organized way to get abstract ideas into code. For others process is an unnecessary bureaucratic slowdown. Many see it as a way for managers to keep themselves busy and avoid real management. Regardless of what your general feelings towards process are, there is probably no process that is more nonsensical to computer programmers than the Waterfall Model.

The Waterfall Model was one of the first computer programming processes that really caught on. It dictates several stages of development. I'm not going to give a primer on the Waterfall Model, Wikipedia can do a better job than I. However the most important feature of the waterfall process, and the reason it is doomed to fail, is that you must know everything about what you want your computer program is to do before you start writing code. In nearly all applications of computer programming, it is impossible to know what a computer program can do that early on in development.

Development is a fluid and iterative process. You try something, it works well, and you expand on it. You try something, it doesn't work, and then you try something else. I have never worked on a project where we knew everything up front. There was always some experimentation and there was always some backtracking to get things working properly.

However we must ask the question, why cant we know everything upfront? Architects can generate all of the blue-prints needed to build a sky-scraper without laying a single brick. Today nuclear engineers can design nuclear warheads without even testing them. So what makes computer programming so different? Why is it that computer programmers are so special that we cannot predict what the outcome of our projects will be?

No comments: