I think we can resolve this debate through a map. I think our problem is a disagreement on what is actually industrialized and predictable vs. What is more exploratory and uncertain.
Most software - but not all - deals with uncertain requirements. These are suited to agile methods.
Other software is in a well understood industrialized domain. Here, I would not recommend waterfall per se, but an approach like Six Sigma and Formal engineering methods certainly makes sense.
A) is how industrialized IoT applications actually are.
It will be 2 decades or more I believe before they are. This will require to lots of disposability and change in the meantime. Hence appropriate for agile.
B) how much indistrialized software will there be in the future? Things like railway systems are well understood and industrialized. And don't need agile. But my point has been there isn't a lot of railway software out there to write anymore.
But at some point, will the newer IoT domains be eventually so industrialized that it requires formal engineering methods? To this I say - sure - but not for a long while. The applications are still too fluid.
C) how many people actually work on various ends of the spectrum of agile vs industrialized ? There has been an explosion of activity in using software in new domains, which is agile by definition. Industrial software even by your own definition only needs to be written once every 80 years. So it makes one surmise it will always be a minority of software development.
Well, whatever Agile means in theory, in practice, it almost always leads to situations like the Android Update situation. Of the Google Chrome Update situation, which is only better because everyone is forced to update.
A situation like the Android update situation, though, is completely unacceptable for smoke detectors or other household devices.
No matter how good predictability is, the demand is that these devices are "buy once, just works™". So we need to write stable software for an unstable use case.
But in no case should we end up with serious devices having a support situation like Android, or the SAMSUNG smart devices.
Yes, it will only be written every few decades, but that is fine. It doesn't need to be a huge industry. Just like Washing Machines are mostly made by smaller enterprises.
I think that the products you're complaining about are in the state they are in because of vendor choices independent of the software development process. If total stability and backwards compatibility are not design requirements, neither Agile nor Waterfall will automatically implement them for you.
I think your class or professors are assigning behaviors and outcomes to development processes that should instead be assigned to the companies or people implementing them.
Most software - but not all - deals with uncertain requirements. These are suited to agile methods.
Other software is in a well understood industrialized domain. Here, I would not recommend waterfall per se, but an approach like Six Sigma and Formal engineering methods certainly makes sense.
Simon Wardley has explained this well here: http://blog.gardeviance.org/2015/06/why-agile-lean-and-six-s...
I think the disagreement is
A) is how industrialized IoT applications actually are.
It will be 2 decades or more I believe before they are. This will require to lots of disposability and change in the meantime. Hence appropriate for agile.
B) how much indistrialized software will there be in the future? Things like railway systems are well understood and industrialized. And don't need agile. But my point has been there isn't a lot of railway software out there to write anymore.
But at some point, will the newer IoT domains be eventually so industrialized that it requires formal engineering methods? To this I say - sure - but not for a long while. The applications are still too fluid.
C) how many people actually work on various ends of the spectrum of agile vs industrialized ? There has been an explosion of activity in using software in new domains, which is agile by definition. Industrial software even by your own definition only needs to be written once every 80 years. So it makes one surmise it will always be a minority of software development.