Waterfall Model

Waterfall Model

Anyone who has taken a software engineering course or has experience in developing software for clients should be familiar with the diagram above. It’s the infamous waterfall model, the approach in software development where projects are split into distinct phases connected serially to each other.

What most developers, managers, and clients who blindly use the waterfall model don’t know is that the 1970 paper that introduced that model (without naming it)–Dr. Winston W. Royce’s “Managing the Development of Large Software Systems“–is ironically a criticism of the model. Zooming in on the text below the diagram:

I believe in this concept, but the implementation described above is risky and invites failure.

The rest of the paper then tries to provide possible ways to mitigate the risks involved in the model. I personally don’t agree with some of his recommendations, but this paper is almost 4 decades old so I’ll let them slide.

I am not saying that the waterfall model is a useless approach to software development. It actually a “best practice“; there are some projects that are better off done using the waterfall model or its derivatives.

As expected from best practices, however, people tend to think that the waterfall method is the best way to produce software regardless of context. I’m fairly confident that this misuse of the waterfall model is the root cause of most failed software projects. Thus, it is imperative that software developers should be familiar with both the risks involved with the waterfall model, as well as the alternatives to the waterfall model in case the risks are too high.

Angry Monkeys

Go near that stepladder again. GO NEAR THAT STEPLADDER AGAIN. I dare you, I double dare you, motherfucker. Go near that stepladder one more goddamn time.

As a follow up to Cargo Cult Thinking and Best Practices, I’d like to share a story used by Dave Thomas (one of the authors of The Pragmatic Programmer) in a keynote Angry Monkeys and Cargo Cults.

I first heard this story from Neal Ford’s presentation on ways to improve your code. Fortunately, the presentation is a short run down of his book The Productive Programmer and this allows me to copy-pastequote the book instead of having to narrate it using my own words.

Back in the 1960s (when scientists were allowed to do all kinds of crazy things), behavioral scientists conducted an experiment where they placed five monkeys in a room with a stepladder and a bunch of bananas hanging from the ceiling. The monkeys quickly figured out that they could climb the ladder and eat the bananas, but every time the monkeys got near the stepladder, the scientists would douse the entire room in ice cold water. You can guess what that generated: angry monkeys. Soon, none of the monkeys would go near the ladder.

Then the scientists replaced one of the monkeys with a new monkey, who had not been subjected to the blasts of water. The first thing he did was make a beeline for the ladder, and all the other monkeys beat him up. He didn’t know why they were beating him up, but he quickly learned: don’t go near the ladder. Gradually, the scientists replaced the original monkeys until they had a group of monkeys who had never been doused with cold water, yet they would attack any monkey that approached the ladder.

The point? In software, lots of practices on projects exist because “that’s the way we’ve always done it.” In other words, because of angry monkeys.

Best Practices

While I was fixing my Google Reader feed for BusinessWorld‘s IT Matters site (they changed from http://www.itmatters.com.ph/RSS/itmatters.rss to http://www.bworldonline.com/RSS/itmatters.rss), one article caught my eye:

IT needs best practices, too!

My first reaction was, “No sh*t, Sherlock!” After reading the article and finding out that it’s not talking about software engineering practices (which I am sure isn’t being practiced by many local software houses) but the low adoption rates of best practices in Auditing and Risk Management in IT departments, my reaction was still “No sh*t, Sherlock!”. I mean, if you’re dealing with foreign clients and yet you’re not familiar with those processes then you have a big problem on your hands. Either that or you know a good place with steak and strippers.

Since we’re at the topic of Best Practices, I might as well cover it in this post.

Continue reading “Best Practices”