Why do we still do it the waterwall way?

Everybody knows that the waterfall way of developing software is very risky. You spend a lot of time writing requierements documents, and then a lot of time programming, and then you get a lot of software to a testing phase... and then you show a lot of software to your users...

In many cases, that leads to a lot of misunderstandings on the requiremetns documents, a lot of bugs in your software and unsattisfied users 'cause they got something they didn't ask for.

I just want to ask myself and maybe make you think about it. Maybe it works for you! Maybe not, and your current stress tells you that. Alberto Gutierrez says on this post:

Waterfall only works if you follow all of its steps and if you don’t make any change to the specifications when you start coding, when a waterfall project fails, most of the times is not because waterfall is wrong but because waterfall doesn’t adapt to the type of software they want to build, Waterfall doesn’t work with software that evolves while it’s been built.

Maybe you only develop this type of projects: everything is sequential and there's never surprises on the way. Most of us don't. So, maybe you'll like to read a little more and examine how are you developing software... as an engineering process or as a craftmanship? Check http://www.makinggoodsoftware.com/2009/07/23/software-development-engineering-or-craftmanship/.

Just one final thought: "Waterfall" is called that way because rivers never flow backwards... contrary to softwre development.

Thanks for reading!