0

I'm currently reading some literature about software development process models. Everywhere I look, I only read the problems with the Waterfall model and how the iterative and incremental development approach solves these problems. But, I cannot find any information about when you should avoid this approach.

So, for what kind of projects should you better avoid iterative and incremental development?

Said Savci
  • 109
  • 2
  • 3
    Note that pure waterfall was hardly ever used in practice. The first time it was mentioned in the literature, it was mentioned as an model to be criticized (see the discussion in https://en.wikipedia.org/wiki/Waterfall_model). The dichotomy between waterfall and incremental is pretty artificial (often used to sell incremental development as something new, and better than previous practices). What you should rather focus on is the granularity of the increments: does one-day of work produce a meaningful increment? Or one week, or six months? The answer depends on the context. – Giorgio Jul 05 '15 at 16:41
  • I certainly can't think of any _software_ projects where iterative development wouldn't be beneficial. Something like a bridge may not lend itself towards iterative development - but I'll look to see if others can think of something. – Telastyn Jul 05 '15 at 16:41
  • 1
    @Telastyn: Even a bridge might profit from a prototype that is built before building the real one. – Giorgio Jul 05 '15 at 16:42
  • A distinction should be made between a prototype that is intended to be thrown away after the "real" version is designed and a "prototype" that is intended to be a seed of the final application. – Gort the Robot Jul 05 '15 at 16:51
  • @Giorgio - sure, but that sort of proof of concept stage is common in Waterfall approaches, and not what most would consider iterative. – Telastyn Jul 05 '15 at 17:08
  • @Telastyn: I think by iterative you mean that you eliminate the distinction between a throw-away prototype and a working product: in an iterative approach all intermediate prototypes are potentially shippable products. IMO this distinction is artificial in practice: you might start with a throw-away prototype and then realize that it is good enough and just needs some cleaning up to be made into a product. Or you might start with the idea of always having a shippable product, but then need to throw away and rewrite parts of it from scratch. – Giorgio Jul 05 '15 at 17:33
  • @giorgio - partially, but only having one "loop" as it were isn't particularly iterative to me. – Telastyn Jul 05 '15 at 18:02
  • @Telastyn the bridge does benefit too. You don't deliver a bridge on each iteration, of course. First iteration is a wind tunnel model, second iteration may be the casings for the pillars, third could be a segment of roadway, etc. etc. – jwenting Jul 07 '15 at 06:00

2 Answers2

1

The need for iterative and incremental development on most software projects comes from the fact that those projects' requirements are in constant flux, and the fact that quickly delivering a prototype then iterating on it seems to produce better results than trying to produce a comprehensive specification before starting development.

The only situation I can think of where this would arguably not apply is one in which implementing the project is easy, but designing it is hard, and once designed it cannot be easily changed. For example, a new programming language, or the embedded software for some physical device, or the device itself (though that's not software anymore). In these cases, getting it right on the first release might be far more important than the ability to release at any moment or respond to change quickly after release.

Of course, there are no absolutes. To go with my programming language example, Clojure was famously designed over the course of two and a half years by just one guy before he released anything to the public. On the flip side, Rust has had many alpha versions that broke core functionality before settling on a stable 1.0 release. I've heard good things about both languages.

Generally speaking, the harder it is to change things after release, the more you want to rely on upfront design and testing rather than prototypes and future iterations. But personally, I would never avoid iterative development; I would at most begrudgingly accept its impracticality.

Ixrec
  • 27,621
  • 15
  • 80
  • 87
  • @lxrec: I agree with you that there is always a tension between upfront design, and incremental development, and that decisions depend on the context: cost of late changes on one hand, and likelihood of those changes on the other. In some domains changes of requirements are more frequent than in others. – Giorgio Jul 05 '15 at 17:36
  • The biggest case for waterfall development is government. Many of the requirements were determined by law ahead of time. Taxpayer money gets divvied out seemingly without regard to the actual timeline. Dates get set by people seeking reelection rather than a successful product. That has waterfall written all over it. – Greg Burghardt Jul 05 '15 at 19:54
1

In some projects, you have to follow a strict development process, which may not be iterative. An example for these is in the aerospace sector when you have to deliver software by DO-178B/C standards and the like.

For one, you do not even have a choice in those cases. You couldn't develop iteratively even if you wanted to. But more importantly, these projects do not lend themselves to iterative development very well either.

Think of writing control software that gets shot into space (literally!). There is no more room for improvement once it's on flight (it's already different if your thing would start to operate on the moon or the ISS, because software patches become possible). Additionally, the hardware being controlled is typically very mature and requirements have been well analyzed and are very seldom subjected to changes.

Similar cases happen in software that needs to be certified. While you can develop those iteratively, there is a certain point at which you have to declare the whole thing complete in order to get the certification. After that, you must not touch the software again, or your certification is void. Again, a scenario that doesn't exactly favor iterative development.

That being said however, I notice more and more software projects in these sectors going for incremental developments (within the unchangeable frame of the required specification standards). Also, great care is taken to reduce the amount of software that cannot be developed iteratively (or just needs certification) and clearly separate it from the remaining software. The monetary advantages of this move are obvious (at least to anyone who has ever seen the cost of software that controls a plane), but it's also the typical text-book advantages of incremental development that the product developers are interested in.

Frank
  • 14,407
  • 3
  • 41
  • 66
  • 1
    you can develop modules iteratively, and have the project as a whole be delivered only when everything is complete. We're doing that right now on another project. We're having to deal with 2 organisations during development, one wants to use SCRUM and the other's firmly stuck in a waterfall setting. So we're using SCRUM internally, but only the final product will be delivered to the maintenance organisation who accept or reject the product based on a high level requirements document they produce a year or more before development even starts. It's not ideal, but it works. – jwenting Jul 07 '15 at 06:03
  • Especially since our contacts in the organisations are flexible enough to make minor changes in the supposedly unchangeable HLD as needed when requirements and insights change during development and testing. – jwenting Jul 07 '15 at 06:05
  • @jwenting: Your story is yet another confirmation that reality is a continuum between the two ideal extremes of waterfall and perfect incremental development. – Giorgio Jul 07 '15 at 06:06
  • @Giorgio yes, it is, kinda. And it's something you see a lot. Incremental changes in testable chunks towards a well defined end result. If the desired end result isn't known before you start the project, there's really no need to start, is there? Of course the desired result can change during development but you must have some idea of what you're going to make before you begin else you may start building a bike and end up with a space shuttle :) – jwenting Jul 07 '15 at 06:09
  • What happens sometimes is that the prototype software is developed iteratively (and often skunkworks-style). Afterwards, the requirements and specs are extracted from a mature prototype. Then the waterfall cycle is formally done (hopefully just once) to satisfy FAA, FDA, and such. – Nick Alexeev Jul 07 '15 at 06:43
  • @NickAlexeev we refer to this as the ice-cone model. First, you create a ball of ice (i.e. working software that does what it is supposed to do) by shaping things freely as you go, then you create a cone to fit underneath it (i.e. the documents your process requirements demand). – Frank Jul 07 '15 at 09:44