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?
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.
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.
