Development Methods : programmer

[-] 9point6@lemmy.world 134 points 2 months ago

A software engineer was not involved in this if waterfall is painted positively.

I think the last time I heard an engineer unironically advocating for a waterfall IRL was about a decade ago and they were the one of the crab-in-a-bucket, I-refuse-to-learn-anything-new types—with that being the very obvious motivation for their push-back.

[-] MechanicalJester@lemmy.world 41 points 2 months ago

Waterfall: Spend 10 years compiling written functional and technical requirements. Cancel the program due to budget overrun.

[-] CidVicious@sh.itjust.works 20 points 2 months ago

Yeah, waterfall would be "you collect requirements to build a rocket to Mars, 2 years later you have a rocket to Venus and it turns out they didn't think oxygen is essential, they'll have to add that in the next major release."

[-] alykanas@slrpnk.net 8 points 2 months ago

Of course because they don’t like being held to estimates and deadlines.

…and when you agree to run it Agile, which calls for closer and continual communications with the users, the first thing they want is a rep to do it for them .

[-] 9point6@lemmy.world 29 points 2 months ago

Yes, silly engineers that don't like being held to unrealistic estimates and deadlines; typically the ones that arise at the start of a project where there are still who-knows-how-many unknowns to find.

Waterfall is the most effective tool for software engineering in a world where the whole world stops once you've planned and only starts again once the project has finished—i.e. a fictional world that doesn't exist. Literally every waterfall project I worked on back in the old days was derailed because something happened that wasn't planned for—because planning for everything up front is impossible and planning for anything more than a handful of eventualities is impractical.

Agile and subsequent methodology comes from realising that requirements will change and that you are better off accepting that fact at the time than having to face it once you're at the end of the current road.

Agile does not mean engineers talking continuously to the users, engineers are hired to do what they're good at: engineering. Understanding user requirements and turning that into a plan has always been product's job regardless of methodology, in agile and similar it's just spread out over the duration of the project, not front loaded. Agile isn't "make the engineers do every proficiency".

[-] idefix@sh.itjust.works 7 points 2 months ago

And here I am, running projects for the past 20 years mostly using agile, and still very much unconvinced about its supposed superiority over waterfall.

[-] MajorHavoc@programming.dev 2 points 2 months ago

Yeah. It's wild!

Waterfall has been a negative term in software from it's very first use in software.

[-] psud@aussie.zone 1 points 2 months ago* (last edited 2 months ago)

I know several who preferred waterfall, but the system I work on is a giant government one and when we were doing waterfall we were in specialist teams working on a small part of the system

At the same time we went agile management also said "everyone can do everything" so we've had to work across the entire system

For the rocket analogy: we started building a rocket under waterfall, but when we went agile we also decided that the rocket motor specialists could also work on fuel tanks and heat shields

[-] NigelFrobisher@aussie.zone 93 points 2 months ago

They forgot the bit where the Waterfall method blew through the budget and deadline about five times over.

[-] criss_cross@lemmy.world 19 points 2 months ago* (last edited 2 months ago)

And it turns out the customer actually needed a blender

[-] SpaceNoodle@lemmy.world 14 points 2 months ago* (last edited 2 months ago)

This is why I always act as if neither exists

[-] magic_lobster_party@fedia.io 72 points 2 months ago

Waterfall only works if the programmer knows what the client needs. Usually it goes like:

Client has a need
Client describes what they think they need to a salesperson
Salesperson describes to the product manager what an amazing deal they just made
Product manager panics and tries to quickly specify the product they think sales just sold
Developers write the program they think product manager is describing
The program doesn’t think. It just does whatever buggy mess the programmer just wrote
The client is disappointed, because the program doesn’t solve their needs

[-] SlopppyEngineer@lemmy.world 43 points 2 months ago* (last edited 2 months ago)

In terms of Mars

Client wants a robot to go to Mars
Project is budgeted and sold to send a Mars Rover
Work starts and after successful test the robot is shown to customer. Customer states he wants to send a Mechwarriors in a drop ship, not a little Pathfinder.
Panic, change requests, money being discussed, rockets are being strapped together with duct tape and the rover is bolted on an old Asimo that is being rebuilt into the smallest Mechwarrior ever the day before launch
Mech Asimo lands successfully, stumbles and falls on a rock after three steps
Customer disappointed

[-] azertyfun@sh.itjust.works 6 points 2 months ago

Eventually Company decides "agile will fix things"
Developers are told to work agile but the only stakeholder they talk to is the PO, who talks to PM, who talks to Sales, who talks to Customers
PM&Sales don't want to deliver an unfinished/unpolished product so they give a review every sprint, by themselves, based on what they think the customer wants (they are Very Clever)
A year or two later the project is delivered and the customer is predictably unhappy.
Management says "how could this have happened!" and does it all over again.

[-] ToxicWaste@lemm.ee 5 points 2 months ago

as someone who has made it through multiple 'agile transformations' in large companies: that's how it usually goes.

however, that is the problem with people being stuck in their way and people afraid of loosing their jobs. PO is usually filled with the previous teamlead (lower management, maybe in charge of 20 ppl). PM & Sales have to start delivering unfinished Products! how else are you going to get customer feedback while you can still cheaply change things? A lot of the middle management has to take something they would perceive as a 'demotion' or find new jobs entirely - who would have guessed that with an entirely new model you cannot map each piece 1:1...

Given these and many more problems i have seen many weird things: circles within circles within circles, many tiny waterfalls... some purists would call SAFE a perversion of agile.

the point is: if you want to go agile, you have to change (who would have thought that slapping a different sticker won't do it?). the change has to start from the top. many companies try to do an 'agile experiment': the whole company is still doing what they do. however, one team does agile now - while still having to deliver in and for the old system...

[-] madjo@feddit.nl 3 points 2 months ago

I've seen so many companies force Agile without changing the management layer and style. Setting deadlines while demanding that teams work Agile. Insanity!

[-] magic_lobster_party@fedia.io 2 points 2 months ago

That’s what we use in my company: a series of mini waterfalls

[-] MonkCanatella@sh.itjust.works 72 points 2 months ago

Seems like the author has never programmed anything

[-] camelbeard@lemmy.world 84 points 2 months ago

I'm getting pretty old so I have experienced multiple waterfall projects. The comic should be

You want to go to mars You spend 3 months designing a rocket You spend 6 months building a rocket You spend a month testing the rocket and notice there is a critical desing flaw.

You start over again with a new design and work on it for 2 months You spend another 6 months building it You spend 2 months testing

Rocket works fine now, but multiple other companies already have been to Mars, so no need to even go anymore.

[-] BlameTheAntifa@lemmy.world 31 points 2 months ago

This is the perfect waterfall analogy.

[-] trolololol@lemmy.world 2 points 2 months ago

This is the way

[-] tyler@programming.dev 13 points 2 months ago

pretty sure they're saying waterfall for building a rocket because that's literally how NASA builds a rocket, including the software. It's terrible for building anything other than a rocket though, because the stakes aren't high for most other projects, at least not in the way that a critical mistake will be incredibly bad.

[-] ToxicWaste@lemm.ee 3 points 2 months ago

i take you have never heard of the V-model. basically you climb the waterfall back up to verify everything. most things that fly within the atmosphere are done that way. pretty sure NASA would do the same.

[-] qevlarr@lemmy.world 3 points 2 months ago* (last edited 2 months ago)

You can assume people here know what waterfall and the V model are.

[-] Knock_Knock_Lemmy_In@lemmy.world 4 points 2 months ago

Depends. I've heard management talk about agile and waterfall, but I've not heard even one manager say V model.

[-] tyler@programming.dev 1 points 2 months ago

You’re right I haven’t heard of that model, but NASA has documented pretty well that it follows waterfall. https://appel.nasa.gov/2018/11/27/spotlight-on-lessons-learned-aligning-system-development-models-with-insight-approaches/

[-] jol@discuss.tchncs.de 11 points 2 months ago

I'm glad I'm not alone. I couldn't make sense of this comic.

[-] MajorHavoc@programming.dev 42 points 2 months ago* (last edited 2 months ago)

These are all accurate, except the first Waterfall one, who also doesn't go to Mars.

[-] Davin@lemmy.world 25 points 2 months ago

Right. They design the whole rocket, spend years to build the rocket exactly according to the design doc, then the rocket explodes on the launchpad and they have to start all over.

[-] keropoktasen@lemmy.world 8 points 2 months ago

That's why testing comes before launching.

[-] madjo@feddit.nl 7 points 2 months ago

The build phase took too much time, you now have 1 day to test all the features and design elements of the rocket, because launch day is tomorrow. Good luck!

[-] Knock_Knock_Lemmy_In@lemmy.world 1 points 2 months ago

So, we need waterfall testing to be separated?

[-] psud@aussie.zone 1 points 2 months ago

We recently saw waterfall versus agile in actual rockets

Blue Origin spent years meticulously designing their rocket. They tested it on the ground. On the first flight it got to orbit, but the first stage exploded while re-entering

SpaceX started building their rocket out of carbon fibre. Changed to stainless steel. Started flying subscale demos, flew high altitude full scale examples to find if their aerodynamics was right, and haven't actually tried for orbit yet

Blue Origin is trying for a last generation rocket (where the first stage is recovered) but bigger, SpaceX is trying to create the next generation where both stages are recovered

[-] makeshiftreaper@lemmy.world 42 points 2 months ago

More accurately the waterfall mission ends up on Phobos only to have to scramble to figure out how to land on Titan because the customer can't tell the difference between moons

[-] galoisghost@aussie.zone 42 points 2 months ago

The Agile Development here is the same result I’ve experienced for every one of these methods. Mostly because of clients/management.

[-] JohnnyCanuck@lemmy.ca 32 points 2 months ago

That's why agile was created. Because people don't know what they want in panel 1.

[-] RizzoTheSmall@lemm.ee 41 points 2 months ago

What's not covered is the 25 years of R&D in advance of waterfall project starting, or that it's delivered 200% over time and cost due to those requirements being insufficient and based on assumptions that were never or are no longer true.

[-] madjo@feddit.nl 1 points 2 months ago

But at least the rocket has an opulent ball room as per the design spec

[-] aghastghast@programming.dev 34 points 2 months ago

Test-driven development: You spend all your time building a gizmo to tell you if you're on Mars or not. A week before the deadline you start frantically building a rocket.

[-] CanadaPlus@lemmy.sdf.org 2 points 2 months ago* (last edited 2 months ago)

TBF the analogy is especially strained for that one. Per another commenter, Boeing actually makes rockets with waterfall, but test-driven only really makes sense for software, where making local changes is easy but managing complexity is hard.

Edit: Actually, there's even software where it doesn't work well. A lot of scientific-type computing is hard to check until it's run all the way through.

[-] fruitycoder@sh.itjust.works 1 points 2 months ago

That's where digital twin engineering HOPES to bridge the gap.

There is definitely a contium of how long it takes to build and test changes where increasly abstract design makes more and more sense vs the send it model

[-] mdhughes@lemmy.sdf.org 13 points 2 months ago

Waterfall: Boeing/ULA does this. Their rockets cost $4B per launch, don't work, strand astronauts. Maybe the next repair/test cycle, if management's dumb enough to keep paying them.

Agile at least launches something.

[-] kambusha@sh.itjust.works 12 points 2 months ago

Seems biased... What's that logo they're trying to hide in the top-right?

[-] Kabaka 13 points 2 months ago

Toggl's old logo.

[-] boonhet@lemm.ee 13 points 2 months ago

Must be OP trying to hide it, Toggl displayed it proudly. The author used to work for Toggl marketing and ask can be seen from this post, did an excellent job. He still has a webcomic, it's just not marketing for Toggl anymore. Here it is

As for bias - it's a time tracking tool, but I don't think they actually shill for waterfall, I think it's just poking fun at the agile methodologies.

[-] rimjob_rainer@discuss.tchncs.de 9 points 2 months ago* (last edited 2 months ago)

Scrum is about transparency, not intransparency for a month

[-] mmddmm@lemm.ee 10 points 2 months ago* (last edited 2 months ago)

Scrum is not about any of the things that Scrum proponents claim it's about.

Specifically, it's not about agility, it's not about velocity, it's not about quality, it's not about including the "customer", and it's only about a kind of transparency that has absolutely no impact on the final product.

But yeah, it's about some kind of transparency.

[-] Atomic@sh.itjust.works 2 points 2 months ago

Specifically, you would have to put in effort to be more wrong.

Go read the scrum manifest.

In reality, companies always adapt for what they think suits them. Very rarely do you actually use scrum completely as intended, that's fine. But you don't blame the cow when the cook burned your steak. You blame the cook.

[-] mmddmm@lemm.ee 1 points 2 months ago

Oh, Scrum has a manifesto now? Where is it?

Or you meant the Agile manifesto, that Scrum breaks half the items and does nothing about the other half?

[-] Atomic@sh.itjust.works 2 points 2 months ago

Perhaps poorly translated, they call it the scrum guide in English

https://scrumguides.org/scrum-guide.html

I don't know what parts you are talking about since you're not specific.

Furthermore. Kanban is just a method of keeping track of who does what and what the progress of that is. You can use kanban in waterfall. You can use kanban in scrum. No one is just using kanban and nothing else. As your post seems to think.

Programmer Humor

Rules