Jay Myers, Software Engineer
October 30, 2015

In this blog post, the author explains why the waterfall model of software development has been rendered inefficient and downright dangerous since the advent of methodologies like Agile.


computer code width=Let’s talk about what you want. Seriously, think about something you want right now, I’ll wait. If you said commercial jet pack, holodeck, or a reboot of Firefly (give it up, too much time has passed and nothing could live up to your expectations) then do me a favor and think of something more realistic. Better yet, think of something that you want your software to do for you. Got it? Ok, now think about six months ago. What would your answer have been? How about a year ago? Two years?

If your answer was the same for all of those questions, then please stop reading this and go make it happen (in fact, why haven’t you already done that?). If it wasn’t, then over the course of time what you want has changed. That makes sense to me – the passage of time brings with it all sorts of new variables. New innovations that can be used, changes in business direction, and changes in requirements are all factors and they crop up all over the place for myriad reasons.

If this makes sense to you, then I hope you’re not developing software using the waterfall model. Waterfall requires that you fully specify how software works and exactly what it will do before any development is started, and then you launch off into development in a continuous effort until it’s complete – ending in one big delivery. Imagine if you extended this kind of thinking to other aspects of your life. What if when you were driving down a highway you calculated the distance to your exit and your desired arrival time, then set your cruise control, locked your wheel in place and started reading a magazine. At the end when you look up from your magazine, assuming you’re still able to, you might very well be exactly where you wanted to be. That’s not really where my mind went in this thought experiment though.

Now, I know this is a rather contrived analogy but that doesn’t stop it from conveying a point – waterfall can be dangerous.

A better solution would be to constantly adjust your speed and direction in order to make it to your destination in one piece (like, you know, driving). This much more intuitive strategy is a lot more like agile than waterfall. Agile, as defined by the agile manifesto and its principles, isn’t very complicated. In fact, the only piece I really want to stress right now is the idea of highly valuing and frequently delivering actual working software.

Working software and a short feedback cycle are essential to effectively guide development. In our analogy, it’s the act of looking up from your magazine and changing your speed or direction to avoid obstacles and stay on track.

Now think back to what you wanted two years ago. If you had mapped out a route to that place and set off without adjusting, would you really be happy with the result right now? Or would you have spent a lot of time developing things that you really don’t need or want anymore?

REFERENCES:

Holodeck: http://en.wikipedia.org/wiki/Holodeck

Firefly: http://en.wikipedia.org/wiki/Firefly_%28TV_series%29

Waterfall model: http://en.wikipedia.org/wiki/Waterfall_model

Agile manifesto: http://www.agilemanifesto.org/

Agile principles: http://www.agilemanifesto.org/principles.html

Jay Myers, Software Engineer
October 30, 2015

In this blog post, the author explains why the waterfall model of software development has been rendered inefficient and downright dangerous since the advent of methodologies like Agile.


computer codeLet’s talk about what you want. Seriously, think about something you want right now, I’ll wait. If you said commercial jet pack, holodeck, or a reboot of Firefly (give it up, too much time has passed and nothing could live up to your expectations) then do me a favor and think of something more realistic. Better yet, think of something that you want your software to do for you. Got it? Ok, now think about six months ago. What would your answer have been? How about a year ago? Two years?

If your answer was the same for all of those questions, then please stop reading this and go make it happen (in fact, why haven’t you already done that?). If it wasn’t, then over the course of time what you want has changed. That makes sense to me – the passage of time brings with it all sorts of new variables. New innovations that can be used, changes in business direction, and changes in requirements are all factors and they crop up all over the place for myriad reasons.

If this makes sense to you, then I hope you’re not developing software using the waterfall model. Waterfall requires that you fully specify how software works and exactly what it will do before any development is started, and then you launch off into development in a continuous effort until it’s complete – ending in one big delivery. Imagine if you extended this kind of thinking to other aspects of your life. What if when you were driving down a highway you calculated the distance to your exit and your desired arrival time, then set your cruise control, locked your wheel in place and started reading a magazine. At the end when you look up from your magazine, assuming you’re still able to, you might very well be exactly where you wanted to be. That’s not really where my mind went in this thought experiment though.

Now, I know this is a rather contrived analogy but that doesn’t stop it from conveying a point – waterfall can be dangerous.

A better solution would be to constantly adjust your speed and direction in order to make it to your destination in one piece (like, you know, driving). This much more intuitive strategy is a lot more like agile than waterfall. Agile, as defined by the agile manifesto and its principles, isn’t very complicated. In fact, the only piece I really want to stress right now is the idea of highly valuing and frequently delivering actual working software.

Working software and a short feedback cycle are essential to effectively guide development. In our analogy, it’s the act of looking up from your magazine and changing your speed or direction to avoid obstacles and stay on track.

Now think back to what you wanted two years ago. If you had mapped out a route to that place and set off without adjusting, would you really be happy with the result right now? Or would you have spent a lot of time developing things that you really don’t need or want anymore?

REFERENCES:

Holodeck: http://en.wikipedia.org/wiki/Holodeck

Firefly: http://en.wikipedia.org/wiki/Firefly_%28TV_series%29

Waterfall model: http://en.wikipedia.org/wiki/Waterfall_model

Agile manifesto: http://www.agilemanifesto.org/

Agile principles: http://www.agilemanifesto.org/principles.html