SoylentNews is people
SoylentNews
from the what-if-you-can't-program-your-way-out-of-a-paper-bag? dept.
Agile Development is hip. It's hot. All the cool kids are doing it.
But it doesn't work.
Before I get into why this "Agile" stuff is horrible, let's describe where Agile/Scrum can work. It can work for a time-sensitive and critical project of short duration (6 weeks max) that cross-cuts the business and has no clear manager, because it involves people from multiple departments. You can call it a "Code Red" or call it a Scrum or a "War Room" if you have a physical room for it.
Note that "Agile" comes from the consulting world. It suits well the needs of a small consulting firm, not yet very well-established, that lands one big-ticket project and needs to deliver it quickly, despite changing requirements and other potential bad behavior from the client. It works well when you have a relatively homogeneous talent level and a staff of generalists, which might also be true for an emerging web consultancy.
As a short-term methodology when a firm faces an existential risk or a game-changing opportunity, I'm not opposed to the "Code Red"/"crunch time"/Scrum practice of ignoring peoples' career goals and their individual talents. I have in mind that this "Code Red" state should exist for no more than 6 weeks per year in a well-run business. Even that's less than ideal: the ideal is zero. Frequent crises reflect poorly on management.
(Score: 5, Insightful) by Anonymous Coward on Thursday January 04 2018, @02:23PM (18 children)
The "waterfall" method is good for keeping a long-term goal as selective pressure.
The "agile" method is good for iterating rapidly via variation and short-term selection.
You need both.
However, I do loathe humanity's propensity to turn every process into a religion; that's what fucks everything up.
(Score: 4, Insightful) by The Mighty Buzzard on Thursday January 04 2018, @02:58PM
You most certainly do not need both. Or either. You need to work whatever process best fits your specific conditions.
That's humans for you. They're hard-wired for religious thinking. Which is to say not thinking. It takes significant effort and the willingness to admit you are utterly wrong to do otherwise. Witness politics, linux init systems, emacs/vim, climate change, etc...
My rights don't end where your fear begins.
(Score: 4, Informative) by turgid on Thursday January 04 2018, @03:00PM (13 children)
The waterfall method is good for nothing except a case study in why human nature and engineering are incompatible with it, and for filtering out the useless PHBs who believe in it because they're too stupid to see it's simplistic limitations.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by JoeMerchant on Thursday January 04 2018, @03:15PM (8 children)
The waterfall method is good for compliance with legal requirements that demand evidence of a waterfall-like staged development process. It's not half bad at making larger project teams stop, think and communicate a couple of times throughout a product development cycle. It's miserable at day-to-day management of anything.
As for Agile, to me it's a bunch of common terms / buzzwords that make everybody feel comfortable that they have some idea of what's going on, and outside the project team makes them feel comfortable that at least _something_ is going on, if not always forward progress. We're presently using Agile to communicate to management that the schedule which they dictated going into the project isn't going to happen, it's going to come in a lot closer to the experienced team members' initial estimates, but... we're spending roughly 20% of our time detailing bi-weekly plans and tracking progress to those plans in order to communicate this up the chain, and as a result we're also increasing staff by roughly 20% to try to keep up the pace... but, at least upper management feels warm and cozy that _something_ is going on.
The danger I see is that if the progress tracking gets too detailed, the overhead grows too high, ballooning the team size which further decreases efficiency due to increased communication needs - it can reach critical mass and expand unbounded - bringing progress to a virtual halt.
🌻🌻 [google.com]
(Score: 4, Informative) by Snotnose on Thursday January 04 2018, @04:12PM (7 children)
Yeah, and it sucks in the real world. My horror story? Around 1990 I was working on a military radar project that required a DSP card called Sky Warrior. Sky Warrior had a mode called chaining, where you could build a chain of DSP operations, tell it to go, and it would interrupt the CPU when it was done. Some 3-4 times faster than feeding it each DSP op one at a time.
I'm a device driver/OS level guy. When I get new hardware I like to play with it because it never works the way the manual says it will. As this was a waterfall project I was allowed to look at the box on the shelf, but not actually plug the card in and play with it. So I did the entire design based on the manual.
Gets to where it's time to actually write the code and guess what? Chaining doesn't work. Contact the vendor, they haven't implemented it because nobody had asked for it yet. Without chaining there's no way to meet my timing requirements.
Even better. When I joined the company I estimated it was a 3 month project, start to finish, including testing/documentation. It wasn't that difficult. We ended up spending a year doing nothing but writing docs, re-writing docs, doing stupid stuff like renumbering 1.2.3.4 to 1.2.4, etc etc. I got fed up and quit after a year. I never actually touched a Sky Warrior, a co-worker had to implement my design. We'd meet for beers and she would tell her tale, she'd be pissed as hell due to the unpaid overtime and career damage this was causing, I was laughing my ass off because I'd been saying for a year "this is gonna fail bigly".
That was the last time I worked on a military contract. I don't have the temperament to stroke my dick for a year doing useless crap, I want to get in, get the job done, and move on.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by maxwell demon on Thursday January 04 2018, @04:50PM (3 children)
Solution: Sue the vendor for not delivering the advertised functionality. Bonus effect: Next time you'll have much better chances of the manual matching the actual product.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Snotnose on Thursday January 04 2018, @05:01PM (2 children)
Rumor was the company was looking into that, but those things are a couple levels above my pay grade. I do suspect the U.S. Navy put Sky Warrior on a do not buy list somewhere though.
The problem with suing? The company was a startup. Doubtful you'd recoup the legal fees. Also keep in mind as I said earlier, especially back in those days it was common for marketing to advertise stuff engineering wasn't scheduled to start for another year, or for new silicon to have pretty bad bugs.
When the dust settled America realized it was saved by a porn star.
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @05:20PM (1 child)
Intel apparently had a part that acted differently depending on 1 undocumented pin strap (it was documented differently for each sku).
They sold this part in two different markets at vastly different prices, but using the same silicon. Long story short, someone fucking up the shipping orders and sent a load of the cheap parts in place of the expensive parts, the staff at the site didn't check the labelling until after they had installed a few of these parts on their product, and then noticed the product ids were wrong. Long story short: There were some harsh words exchanged over their pricing and the fact that the much cheaper part worked exactly the same (having in fact gone through the exact same testing regime.)
(Score: 2) by Snotnose on Thursday January 04 2018, @08:51PM
While we're telling funny stories. Early 80's, early days of robots putting parts in holes on boards (called pick and place). Got a batch of 30 or so boards that didn't work. I was a tech at the time and grabbed one. Very strange patterns on my O'scope.
Turns out whomever loaded the pick and place machine had put a reel of resistors where caps were supposed to go, and put the reel of caps where the resistors were supposed to go.
After 30 years bet I've got more stories than 90% of you young whippersnappers who covet my lawn.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by JoeMerchant on Thursday January 04 2018, @05:12PM
By 1990 "Military Intelligence" was already a well known oxymoron.
Sounds like you're out of sync with your employers and co-workers. Sure, it's 3 months of technical work, but isn't it better to get paid for 2 years? Now, if they're doing unpaid overtime, it sounds like they squeezed too hard while milking their particular cow...
Around 2000, I joined a med-device company that was in the process of "shrinking" their current design. The project was at 2.5 years since launch with an original forecast of 2 years total development time. I was assigned "Principal Engineer" of the existing design in production, which basically meant not signing off on boneheaded production change proposals while looking for something real to do. I hung around there for 2.5 years, sticking my nose in the development project because it was the only "new thing" going on, and watched them sit and spin the whole time. After I left, it was another 3 years before the "new thing" launched, nearly 8 years in development, all to take the existing functionality and put it in a smaller box (and they had prototypes up and running within 1 year...)
🌻🌻 [google.com]
(Score: 2, Informative) by Anonymous Coward on Thursday January 04 2018, @05:49PM
If you weren't allowed to write your software using the actual hardware it would be running on (and the hardware actually existed already so you could have tried it) then that isn't waterfall, that's simple mismanagement and a dishonest vendor. Let's count up the problems:
* buying a product based on advertising without verifying the performance
* delaying testing until it's too late to fix anything
* committing to a supplier without letting your own engineers vet them
None of that is specified by waterfall! Not that waterfall is super great, but these aren't reasons it's bad. Just that project was bad and it happened to also use waterfall.
For what it's worth, none of these are uncommon, either. I've had all of them happen to me - though certainly not all at once. One was even sort-of my fault (for not double checking everything the vendor did even though I had a warning sign).
(Score: 2) by turgid on Thursday January 04 2018, @09:39PM
This 100%
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by Anonymous Coward on Thursday January 04 2018, @06:10PM (3 children)
The waterfall method works fine in every other engineering discipline (try replacing a bridge in an agile way). The reason it doesn't work for software development is simple (at least imnsho): software development as currently practiced is neither engineering, nor a discipline. Software development is practiced the same way that the Egyptians practiced astronomy: we know just about enough to predict seasons and to tell the time, but other than that we're very much beholden to rituals (as in TFA), cultism (see any programming language discussion) and handwaving (see any software documentation).
It's hard enough to take any software seriously these days without everyone cargo-culting along with the latest fad. But the development process isn't even the core of the problem: the #1 problem is that the landscape is fragmented into too many silo's: whether it's ruby vs python, or mongo vs cassandra, or java vs dalvik vs dotnet vs objc, or gnome vs kde, it's almost impossible to easily adapt code from one silo to another, leading to massive wasted effort on solving already-solved problems -- they're just not solved in your framework-du-jour. And naturally, all players seem more focused on expanding their captive base than improving software development as a whole.
That's one thing where I hope that data-driven architectures and microservices (cult alert!) can improve the situation: at least the microservice approach requires a documented interface layer for every minor component.
(Score: 2) by turgid on Thursday January 04 2018, @08:59PM (1 child)
You can't directly compare physical engineering with software engineering.
Agreed, but there's more too it than that. I've thought a lot about this over the years, and I have my very own Secret Plan for World Domination(TM) which I am working on. If it ever gets useful, I'll GPL it.
It's always been like that. Even when my father was a young man in about 1969 when he first wrote some engineering code on a mainframe.
You can open the bonnet of a car and look at the engine. You can't "see" software. You can't evaluate it just by looking at it. You have to read the source. You have to execute it in test harnesses. Everyone who reads the code will have a slightly different understanding of it. Good luck getting any PHBs to remotely comprehend any of it, and people who use Eclipse and Visual Studio.
Big software is developed in teams and it takes many months for a team to come together. Even then, everyone has their own pet ideas about how to do things. Ten years ago I landed on my feet, and it has set me up well. Too much to talk about here...
That does have its advantages, though. Monocultures are bad, in nature and engineering.
There is a book (for physical engineering) I must read some time. It's called Simplified Triz (? IIRC). Design Patterns are kind of like that for software but... I need to read it.
Indeed.
Sounds like attention to detail in modelling and specification... But still too manual.
I really must do some more work on my secret plan.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday January 05 2018, @01:20AM
Yes, this complicates things, but that also applies to microelectronics and (cellular) biology. Yet, we seem to know a lot more about those mechanisms than we know about the software we use in our programs. And that's odd, given that the software has been designed by ourselves, not by nature -- we shouldn't need to "discover" anything about it.
In order for software development to become proper engineering (in other words, to advance from astrology to astronomy), what we need is better tooling. And I don't mean that in the compiler/editor sense, but in the scientific sense: better language to unambiguously describe it, better metrics to evaluate it (not just performance, but reliability, robustness, completeness), better analysis to predict future behaviour (fuzzing and testing frameworks are a step in the right direction at least).
Yup, I didn't mean to imply monoculture here. I very much want a diverse software ecology, but one where interfacing with other components is as easy as just importing it into your build system -- the component specs should be extensive enough for your build system to automatically generate the correct bindings. Ah, one can dream...
(Score: 2) by acid andy on Friday January 05 2018, @03:22AM
In many cases that's because of the Pointy Haired Bosses rather than the developers. The single biggest problem is most PHBs don't respect the dev's estimates of how long the task will take. They don't learn from experience that it will wind up taking that long anyway.
I will say though that there's something very strange about trying to complete a very detailed design without exploring any code at all. I never got the point of things like UML (unless where used to communicate the architecture of already-written code to someone who can't read code). It's always seemed many, many times more efficient to me to knock together some (at the very least pseduo-) code and reverse engineer the design from that. Of course, you don't need to tell anyone that you wrote that code! Hell, even with the bridges I bet they build scale model prototypes sometimes.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 3, Insightful) by Anonymous Coward on Thursday January 04 2018, @03:33PM
Fuck "Agile". It's about coding shit in a sloppy way as fast as possible, and then throwing the baby with the bath water when the business changes their mind. Both are totally at odds with each other. The expectations is you can make dynamic enough things that you can change really fast in a time-frame that only permits really static changes. It's fucking retarded.
Now "Waterfall" is the exact opposite so just as useless. You have enough time to code shit very dynamically so it becomes more flexible, but the things you code will almost never change because the process resists any changes with mummy level of red-tape.
At least this is my take on the whole bullshit. And I think both are snake-oil, sold by confidence men with books and training materials for an extra fee!
(Score: 5, Funny) by DannyB on Thursday January 04 2018, @03:45PM
The Vogons insist it is not a religion. And did you fill out the correct form in order to do a commit?
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @05:00PM
Indeed. Somebody here got hot on "microservices" and "web APIs" and bloated our code-base up to about 4x what it would be for no known practical reason other than some unspecified future event(s) will somehow take advantage of them.
Microsoft is hyping it because they want you get to get used to hooking up to and subscribing to their web-based services. MS doesn't care much about OUR productivity, they just want a fatter wallet, and feed the PHBs BS to get it.