3 ms·

"you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs

"you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that." I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors. The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain. Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.

kuschku 11y ago
Well, if companies build their software depending on yours, before you have even written a single line of code, and if your software is supposed to run for decades, agile – which is better suited for constant change – is not ideal. And this piece of software exists. Governmental projects interacting with lots of insurance companies, for example. Like the Elektronische Gesundheitskarte – a concept of giving every German an insurance card issued by the government, with all medical data stored in a cloud with insurances, doctors and pharmacies having access to it. Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards. Breaking anything at that point costs millions. EDIT: regarding your edit: Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years.
- parasubvert 11y ago
  "Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards." Yes. There are hard constraints in many projects. If you know exactly up front what you need, you do not need Agile approaches to handle the uncertainty. However, there is plenty of uncertainty to be managed behind this API. "Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." One doesn't have to change an API to evolve the software. Old school HTML and HTTP from 1992 still works on an evolving web. "But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." APIs can be made to be backward compatible or versioned as they evolve. Again, you presume the people asking for the software know exactly what they want. IF they do, then you are fine. It is very rare in practice except for simple or well-understood predictable domains. If the stakeholders do not know or agree on what they want (most of the time), something like Agile is appropriate to manage change. Most APIs evolve a lot as parties learn more about the problem space, but this does not necessarily mean older versions automatically break. This really has little to do with Agile vs. Waterfall, it has more to do with the design decisions made for evolvability.
  - kuschku 11y ago
    > Old school HTML and HTTP from 1992 still works on an evolving web. Actually, not. Try <blink><marquee>TEXT</marquee></blink> Most browsers stopped supporting that. And many other features, especially in CSS, constantly change and evolve, often older variants being dropped. Especially Chrome is dropping support for older code all the time. (Also, soon CSS newspaper-like column flow will be dead T_T ) Even if the people you work for don’t know what they want, the part of "determining what they want" should be part of the "find the requirements" at the begin. You might even want to work with mockups or proof-of-concepts at this time.
- rbanffy 11y ago
  Like pointed out before, you need more experience before you can make claims like the ones your teachers make. They probably need it too. What you describe is a problem stated in great detail and an API that's needs to be kept backwards compatible. There is nothing in agile that precludes that. Quite the contrary: if you build your tests well enough, everyone who did not participate in the original design can use them as examples of how your system actually works. More than that: you can always prove your system still works as specified, all the time, every time. Agile is good, very good, for dealing with a changing world. And, while the APIs in the system you describe can't change without major investment, if the rest is also difficult to change, whoever did it did it seriously wrong. You can tell that to your teachers.
  - kuschku 11y ago
    Well, we aren’t in that class to learn how to write software, but how to apply engineering principles to software. And if you buy a washing machine with lifetime guarantee, you expect it to run forever, but the requirements are mostly static, too. For a smart TV, on the other hand, you separate the pieces of software with static requirements, and those without. The internal signal decoder, etc will be static. UI might end up rendered by a local web browser, and especially media content will be online. So if, in 10 years, Netflix defaults, the online content can immediately remove Netflix and replace it with its successor. This UI might make sense with Agile. But the code the user expects to be reliable and fast – like the code for decoding and displaying a TV signal – will not change, and should be written with waterfall. ---------------- In our world, people are constantly complaining about change. People don’t want to buy a new phone every 2 years, they want to buy one phone one time, and be able to use it for 10 years. At least. People want to be able to buy a fridge or washing machine and use it for decades. Do you buy a new fridge every year? We are going to be living in a world with internet of things. And with the internet of things we will have shoes and houses running software. More and more software will have to be built with the expectation never to get updated.
    - parasubvert 11y ago
      My Mercedes-Benz has software firmware for my transmission that is updated annually, at the shop. The software can be updated over the air in a Tesla every few weeks. Mercedes is working with my company to adopt agile practices and server deployment to disposable cloud environments for their connected car IoT applications. Industrial and Appliance manufacturers such as Philips, and GE (a 10% investor) are also adopting this same software and methodology for their IoT platforms and applications. I don't know what else to tell you - there are certainly areas where you correctly point out you need to get it right the first time. But you keep making projections about the future of immutable software that are contradictory to all the evidence. The world is a big place and even in Deutschland the big industrial manufacturers are adopting lean and agile. Cars at Toyota and Honda (and many others) are developed with Lean Product development principles - not a big up front design plan, but test-first, concurrent, iterative, incremental engineering. One can buy hardware that lasts a decade - the software can and will evolve except in constrained environments. A washing machine is not a constrained environment.

kuschku 11y ago

Well, if companies build their software depending on yours, before you have even written a single line of code, and if your software is supposed to run for decades, agile – which is better suited for constant change – is not ideal. And this piece of software exists. Governmental projects interacting with lots of insurance companies, for example. Like the Elektronische Gesundheitskarte – a concept of giving every German an insurance card issued by the government, with all medical data stored in a cloud with insurances, doctors and pharmacies having access to it. Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards. Breaking anything at that point costs millions. EDIT: regarding your edit: Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years.

parasubvert 11y ago
"Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards." Yes. There are hard constraints in many projects. If you know exactly up front what you need, you do not need Agile approaches to handle the uncertainty. However, there is plenty of uncertainty to be managed behind this API. "Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." One doesn't have to change an API to evolve the software. Old school HTML and HTTP from 1992 still works on an evolving web. "But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." APIs can be made to be backward compatible or versioned as they evolve. Again, you presume the people asking for the software know exactly what they want. IF they do, then you are fine. It is very rare in practice except for simple or well-understood predictable domains. If the stakeholders do not know or agree on what they want (most of the time), something like Agile is appropriate to manage change. Most APIs evolve a lot as parties learn more about the problem space, but this does not necessarily mean older versions automatically break. This really has little to do with Agile vs. Waterfall, it has more to do with the design decisions made for evolvability.
- kuschku 11y ago
  > Old school HTML and HTTP from 1992 still works on an evolving web. Actually, not. Try <blink><marquee>TEXT</marquee></blink> Most browsers stopped supporting that. And many other features, especially in CSS, constantly change and evolve, often older variants being dropped. Especially Chrome is dropping support for older code all the time. (Also, soon CSS newspaper-like column flow will be dead T_T ) Even if the people you work for don’t know what they want, the part of "determining what they want" should be part of the "find the requirements" at the begin. You might even want to work with mockups or proof-of-concepts at this time.
rbanffy 11y ago
Like pointed out before, you need more experience before you can make claims like the ones your teachers make. They probably need it too. What you describe is a problem stated in great detail and an API that's needs to be kept backwards compatible. There is nothing in agile that precludes that. Quite the contrary: if you build your tests well enough, everyone who did not participate in the original design can use them as examples of how your system actually works. More than that: you can always prove your system still works as specified, all the time, every time. Agile is good, very good, for dealing with a changing world. And, while the APIs in the system you describe can't change without major investment, if the rest is also difficult to change, whoever did it did it seriously wrong. You can tell that to your teachers.
- kuschku 11y ago
  Well, we aren’t in that class to learn how to write software, but how to apply engineering principles to software. And if you buy a washing machine with lifetime guarantee, you expect it to run forever, but the requirements are mostly static, too. For a smart TV, on the other hand, you separate the pieces of software with static requirements, and those without. The internal signal decoder, etc will be static. UI might end up rendered by a local web browser, and especially media content will be online. So if, in 10 years, Netflix defaults, the online content can immediately remove Netflix and replace it with its successor. This UI might make sense with Agile. But the code the user expects to be reliable and fast – like the code for decoding and displaying a TV signal – will not change, and should be written with waterfall. ---------------- In our world, people are constantly complaining about change. People don’t want to buy a new phone every 2 years, they want to buy one phone one time, and be able to use it for 10 years. At least. People want to be able to buy a fridge or washing machine and use it for decades. Do you buy a new fridge every year? We are going to be living in a world with internet of things. And with the internet of things we will have shoes and houses running software. More and more software will have to be built with the expectation never to get updated.
  - parasubvert 11y ago
    My Mercedes-Benz has software firmware for my transmission that is updated annually, at the shop. The software can be updated over the air in a Tesla every few weeks. Mercedes is working with my company to adopt agile practices and server deployment to disposable cloud environments for their connected car IoT applications. Industrial and Appliance manufacturers such as Philips, and GE (a 10% investor) are also adopting this same software and methodology for their IoT platforms and applications. I don't know what else to tell you - there are certainly areas where you correctly point out you need to get it right the first time. But you keep making projections about the future of immutable software that are contradictory to all the evidence. The world is a big place and even in Deutschland the big industrial manufacturers are adopting lean and agile. Cars at Toyota and Honda (and many others) are developed with Lean Product development principles - not a big up front design plan, but test-first, concurrent, iterative, incremental engineering. One can buy hardware that lasts a decade - the software can and will evolve except in constrained environments. A washing machine is not a constrained environment.