Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum is the new waterfall

adambourg.com

Post reply on HN
Print view View original

111–120 of 183 posts

Re: Scrum is the new waterfall

#111

Post by parasubvert »

kuschku wrote: post #106
rjspotter wrote: post #95

Earlier quoted context omitted.

Healthcare.gov was also a healthcare application developed waterfall style and was an enormous failure on launch day because of it's interactions with 3rd party systems.

And now imagine Healthcare.gov was Agile and its API would change every month completely. And then imagine how every insurance would complain and how, after 2 or 3 months, everyone depending on healthcare.gov would have stopped supporting it because after the third rewrite of the parts of their software interacting with healthcare.gov’s API they’ve gone mad. Every time you interact with third parties you have to prov…

"And now imagine Healthcare.gov was Agile and its API would change every month completely."

This is not required by any Agile method that I have experienced. You can create a stable API and stick with it forever. If you know what you want/need.

"Every time you interact with third parties you have to provide stable interfaces."

Yes. Case in point, the Cloud Foundry APIs at http://apidocs.cloudfoundry.org are backwards compatible and stable behind a dozen or more agile projects. Changes are made continually on the codebase, but the API remains stable, so that interoperability is not broken as new features are added.

Re: Scrum is the new waterfall

#112

Post by rbanffy »

kuschku wrote: post #86
parasubvert wrote: post #84

Earlier quoted context omitted.

"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, pe…

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 Germ…

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.

Re: Scrum is the new waterfall

#113

Post by kuschku »

parasubvert wrote: post #104
kuschku wrote: post #86

Earlier quoted context omitted.

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 Germ…

"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 environmen…

> Old school HTML and HTTP from 1992 still works on an evolving web.

Actually, not. Try

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

Re: Scrum is the new waterfall

#114

Post by jdbernard »

kuschku wrote: post #98
jdbernard wrote: post #78

Earlier quoted context omitted.

I'm very curious, what is your definition of waterfall?

The classical definition: 1. You research the actual requirements, including by testing some possible alternatives via mockups, etc. 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You verify it matches the design and fulfills the requirements 5. You release it and maintain it. Most importantly, after Step 2 your APIs don’t change anymore. This is especially important as…

Matthew already highlighted the concerns. So, hypothetically, what happens when just after you finish step 3 it is found that one of the core security mechanisms that the security of your life-critical product depends on and that was part of your published API is suddenly found to be insecure due to some new breakthrough in a research lab somewhere? Do you throw it all away and start over from step 1?

Or what happens when, again at step 3, you discover that one of he approaches advocated by the design, and tested by the mockup in the small is unacceptably non-performant when scaled to the real load? Or some other constraint that was not fully tested by the mockups?

You can't say "well, we do a better job with the mockups." If the mockups covered 100% of the functionality and requirements of he system they wouldn't be mockups, they would be the product.

And if your answer is, "well we do this kind of discovery in the testing and mockup phase, changing the mockups to reflect the issues we encounter," congratulations, you are doing Agile development.

Re: Scrum is the new waterfall

#115

Post by kuschku »

rbanffy wrote: post #112
kuschku wrote: post #86

Earlier quoted context omitted.

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 Germ…

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 the…

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.

Re: Scrum is the new waterfall

#116

Post by Joof »

rbanffy wrote: post #66
matthewmacleod wrote: post #38

Earlier quoted context omitted.

Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. No, it doesn't. Bad management and process leads to that. But often refactoring the system, rewriting subsystems, etc is necessary. Totally acceptable and something that can easily be included in agile development. If your software is working, but there is no documentation This is not a prerequisite of agile…

>> If your software is working, but there is no documentation > This is not a prerequisite of agile development. What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.

As an aside; I've been playing with rust and it's built-in documentation solution has an interesting quality to it. Code snippets in documentation are compiled and can be tested at compile time.

It's one excellent way to ensure that updates that necessitate a change in documentation actually get documented.

Re: Scrum is the new waterfall

#117

Post by rbanffy »

Joof wrote: post #116
rbanffy wrote: post #66

Earlier quoted context omitted.

>> If your software is working, but there is no documentation > This is not a prerequisite of agile development. What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.

As an aside; I've been playing with rust and it's built-in documentation solution has an interesting quality to it. Code snippets in documentation are compiled and can be tested at compile time. It's one excellent way to ensure that updates that necessitate a change in documentation actually get documented.

I love using doctests in my Python code. They can't replace proper tests, but its great to be able to guarantee your docstrings are correct.

Re: Scrum is the new waterfall

#118

Post by parasubvert »

The problem is that Scrum is rather lukewarm agile. It's mostly about toe-dipping, not making big changes in how you think about how you work. It can lead to this, but it just really often doesn't.

Firstly, Scrum too often becomes the waterSCRUMfall - you don't deal with the problem end-to-end, you insert a version of Scrum in the middle of a broken organizational context.

Secondly, Scrum also mostly has a lot to say about team organizational structure, reporting, and process (which managers like) but not so much about software development practices (which help you do your job). This can lead to busy work and misinterpretation from those who "manage" software rather than those who "do" software.

Thirdly, I have a theory that a lot of the fallout from Scrum and agile not working is due to people trying to find something easier to digest than Extreme Programming, which includes nearly all the development practices that scrum teams pick and choose. Once you look for something easier to adapt to, meaning you don't have to change everything, it becomes easier for agile consultants to keep modifying the already lukewarm process to be a 10% improvement of the mess you already have rather than a leapfrog replacement.

And the few times a leapfrog is OK, it requires a lot of organizational air cover and buy-in, top to bottom, because you can't "force" people to work in a very different way without it being rejected.

My view is - if your approach to building software is broken, and you want to do something different, you have two choices:

a) build a process organically from the top down and bottom up simultaneously - perhaps a mix of Kanban for change management, and individual development practices that the software teams & senior developers want to do.

b) if you have the willpower and lack the knowledge or patience, adopt a "more extreme" agile method like Extreme Programming, and complement it with organizational change management techniques like Kanban. And ensure you have people or partners that can really help you with it (at all levels - not just as "coaches").

Finally, Kanban is not a software development process. It's a change management process. You an evolve a software development process out of Kanban and picking/choosing from other ideas from XP or others. Kanban is good in that it allows you to tailor an approach that deals with "big picture" organizational change issues first -- trying to do too much and piling up requirements inventory or work-in-progress. But it doesn't say anything about how to build software.

Re: Scrum is the new waterfall

#119

Post by kuschku »

dragonwriter wrote: post #110
kuschku wrote: post #106

Earlier quoted context omitted.

And now imagine Healthcare.gov was Agile and its API would change every month completely. And then imagine how every insurance would complain and how, after 2 or 3 months, everyone depending on healthcare.gov would have stopped supporting it because after the third rewrite of the parts of their software interacting with healthcare.gov’s API they’ve gone mad. Every time you interact with third parties you have to prov…

> And now imagine Healthcare.gov was Agile and its API would change every month completely. Most methods that get the "agile" label attached to them focus on managing change by organizing work in such a way that, outside of externally driven changes that the organization can't control (which have the same effect regardless of development method) the parts that are done don't change much after they are released, to av…

If the parts that are done don’t change much, it’s not Agile.

Agile is if no piece of your software can ever be called "done" because you are constantly changing things to be able to react to the market, as the market always changes.

If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile.

Re: Scrum is the new waterfall

#120

Post by kuschku »

jghn wrote: post #89
kuschku wrote: post #23

Earlier quoted context omitted.

At the university where I am, we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest. And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible…

My experience with taking such classes at multiple schools was always that any CS class talking about Real World Software Development turned out to not be all that accurate. Which perhaps makes sense since computer science isn't really about software development, real or otherwise. My favorite was being chided by a phd student teaching assistant that I needed to understand how things worked in industry if I wanted to…

The issue here are systems like Internet-of-Things devices.

90% of the people buying your smart washing machine will never ever update it. Never.

So change is non-existent in the code you are delivering.

And we’re going to have more and more IoT devices.

Already today we’re seeing Smart TVs with preinstalled apps for online streaming sites that don’t even exist anymore.

We have to be able to separate those pieces of code that will surely change and require constant change from those that will never get updated.

Post reply on HN