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?
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(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.
(Score: 4, Interesting) by turgid on Thursday January 04 2018, @02:53PM (8 children)
I've been at precisely two companies where they did Agil/Scrum properly.
The first, the team I joined in a junior position, was an early adopter in a large organisation doing the whole Lean Six Sigma thing. They took it seriously. At first, they got a lot wrong but with perseverance and training, we got it down to a fine art. In the end three of us were developing and maintaining a 750k line cross-platform code base, delivering to 500k customers.
The second place also did it properly, and got good results, because I instigated and implemented it, supervised, trained and mentored. I got big bonuses and pay rises.
Next I found myself in a different industry. They still think Agile is new and don't really understand what it's about and don't seem to want to listen...
Now we have the Interwebs full of nay-sayers giving us their personal ignorance on the subject.
It's four days into the new year and I already need a holiday.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by tibman on Thursday January 04 2018, @03:15PM (5 children)
This is the part where most companies seem to fail. They say "let's try this thing" and it goes poorly. They forgot how long it took for them to evolve their current system and when the new system fails to go perfectly they throw it out like garbage. A lot of people resist the new system too.
Waterfall works better when your specs never change and business doesn't re-prioritize stuff. I never see that with software. Though, i am in a "fast changing" software industry. Might be different for people writing device drivers.
SN won't survive on lurkers alone. Write comments.
(Score: 3, Informative) by turgid on Thursday January 04 2018, @03:20PM (3 children)
I used Agile/Scrum/TDD for writing specialist device drivers. The company previously had a track record of abandoned, late and buggy products. This one got 100% "customer satisfaction." Unfortunately that meant they thought they could keep cutting the software engineering budget... Bloody PHBs.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by tibman on Thursday January 04 2018, @08:20PM (2 children)
Ouch! Maybe you have discovered the real reason why engineers hate TDD? : P
We test a lot at work but don't practice TDD as a religion. It does certainly result in less production support required.
SN won't survive on lurkers alone. Write comments.
(Score: 3, Interesting) by turgid on Thursday January 04 2018, @09:12PM (1 child)
Religion and science/engineering don't mix, in general.
What continually amazes me is the number of people apparently older, wiser and more intelligent than me that think they don't need TDD because they're so great and their code is so marvelous. They apparently haven't heard of the four stages of competency, or think they're already at the top: 1 Unconscious Incompetent, 2 Conscious Incompetent, 3 Conscious Competent, 4 Unconscious Competent.
You should never get to stage 4 when writing code for the following reason. If you do, then you're doing something you already did before, so why aren't you reusing it?
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, @02:25AM
Religion and science/engineering don't mix, in general.
Yes, but sometimes they work out amazingly well.
Religion is basically faith.
Part of what got Apple to where they are not was the faith of SJ in knowing where to go.
(Score: 2) by Snotnose on Thursday January 04 2018, @09:01PM
LOL. Lessee, I wrote for custom hardware back in the 80s. Did a lot of Ethernet and DMA in the 90s. Did a lot of PCI and 802.11 in the 00s. On to video/display drivers recently. In between add a couple USB, Firewire, disk controller, and other custom boards.
Every project has a new chip with new features that is different enough that if you're lucky you can reuse the int main() {}.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by frojack on Thursday January 04 2018, @06:09PM (1 child)
Well then, I'm sure we got an unbiased evaluation of that success.
Yet you moved on to a third company. Or did the second company move you on?
No, you are mistaken. I've always had this sig.
(Score: 2) by turgid on Thursday January 04 2018, @08:48PM
No, they kept cutting the budget. It was great for the share price, not so good for actually having the resources required to get the work done. I left to go to a growing industry and a company with a better long term future. Shame they're a bit behind on software engineering practices, but that will improve.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Interesting) by Nerdfest on Thursday January 04 2018, @02:57PM (8 children)
I find Agile is the worst form of development project methodology ... except for all the the others. Seriously, perhaps other have had better experience, but I've never had the project requirements anywhere near firm enough to do a proper waterfall project, and that's in 35 years or so. Agile would have, or did work better in all of the ones I've worked on. Seriously, even if you have all the requirements, I don't really see any downsides, other than it generally being more taxing as a developer as there are few 'quiet' times. Just allocate a bit of time every day to do some learning, some tech reading, etc.
Where it runs into problems is where you need to interface with 'gatekeeper' sort of process, like security and other compliance reviews. It can work, but it's better if you work with that sort of group throughout development so that it's not 'throw it over the wall and see what happens'.
(Score: 2) by turgid on Thursday January 04 2018, @03:02PM
Wise words.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Nerdfest on Thursday January 04 2018, @03:06PM
I should add to this that to contradict more of what's in TFS, it's a *great* way to do mentoring a training (occasional pair programming, code reviews), great for spreading knowledge of systems as a whole (small clearly defined tasks in different areas of the system). Basically the complaint seems to match what I mentioned above, that it's *too efficient*. Yeah, that's not a bad thing. Waiting for more work to be tossed your way, clients to confirm and review specs, waiting for client testing .... as a developer I find *that* hard, especially when they're slow but *my* deadline never changes. I've heard the complaint about agile from some clients, as it does involve them a lot more and they can't hide behind waterfall delays either.
(Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @03:40PM (1 child)
There is no waterfall or agile. If you have gatekeepers then at best you have waterfalll. If you say you have agile and it takes 12 weeks to fix and test a bug, you do not have agile just unplanned development. I been in this bus for 45 yrs, there is no agile or waterfall in business just the thought that is the name you want to call it.
It is small teams 3 to 4 developers, you are agile, since they all know what is happening. If you have more and lots of gatekeepers, you are waterfall.
The only group that I have ever seen were doing software right and as true waterfall, is for space shuttle. If that was done wrong people die.
(Score: 2) by Nerdfest on Thursday January 04 2018, @05:59PM
For gates, I just let the customer choose when, and how often to take the hit. In large orgs, it's beyond my control to change that part, so they can balance how long they can do without the functionality they need versus how much effort it is for the gating process.
(Score: 2, Interesting) by Anonymous Coward on Thursday January 04 2018, @03:52PM (1 child)
So how does a company move from Agile As An Excuse ("We don't have time for requirements, they slow us down. We're agile now, so go away. We don't have to talk to you anymore.") to Agile as a fast/effective way to actually meet requirements set by those gatekeepers?
Gatekeeper Requirements which apparently get in the way, such as: "The Policy says thou shalt use encryption when storing sensitive data." "Thou shalt pull data from its System of Record and not just any old System of Convenience." "Thou shalt not reinvent the wheel for a fifth time without first explaining why none of the previous four implementations will meet your needs."
(Score: 2) by Nerdfest on Thursday January 04 2018, @06:04PM
They don't "Get in the way", they just are generally set up so that they won't even look at a project until it's complete. Then after it's been through once, they pretty much insist on the same amount of time or money for the next iteration as well rather than working with a dev team and looking at what was changed. You know, perhaps even advising in advance. They're waterfall based gates because they say they are, and that's the way they've always done it.
I'd also guess that the space shuttle systems requirements were extremely well thought out over years. It has nothing to do with people's lives on the line. For that, you test, not trust a fucking process.
(Score: 2) by Thexalon on Thursday January 04 2018, @10:35PM (1 child)
My opinion: The problem is thinking that there's any kind of consistent project management ideology or system that works for all situations. It's another manifestation of the first myth of management, namely that managers can really control what actually happens in a business.
Agile ideas are good for those situations where (a) the people outside of the tech organization have only a vague clue about what they need, and (b) the tech organization in question is either in-house salary, or outsourced and paid per programmer-hour or something similar. This allows the tech organization to slowly tease out what the people outside the tech organization really are after with minimal investment of programmer time, and also allows the tech organization to bleed whoever's paying them rather than themselves when bike-shedding is going on. The big problem is that all the stupidity of scope negotiation with waterfall doesn't go away, it just moves from "Is this in scope?" to "Is this part of the minimum viable product?"
Waterfall ideas are good for those situations where the people outside the tech organization have a very clear idea about what they need (e.g. a backend thing that nobody outside of tech really understands but has a regulatory checklist to satisfy). In those cases, the requirements are fairly fixed, so there's less arguing over what's in and what's out of scope. And because the target is relatively fixed, architects can design things to make sense given the known goal. Of course, it's hopeless when people start changing their mind about the requirements mid-stream.
And neither of them handle what is the bulk of many corporate coding jobs, which is fixing bugs. And that's because those are darn-near impossible to project-manage and schedule - nobody has any idea before they start whether the bug in question will be something really quick and simple, or whether the bug in question will involve a 1-line tweak, a simple modification to a function, or a complete redesign of a subsystem.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @10:35AM
True, bugs are hard to estimate, but you are exaggerating (after all, none of the development can be estimated exactly).
In many cases, a vague bug description allows categorizing, e.g. "that should never happen, but there's likely only a couple of ways it could have happened", "oops, we never even considered this", etc.
You can often get a gut-feeling estimate.
Also, as an aggregate, you are usually not far of in allocating the same time for debug as for development.
(Score: 5, Funny) by Anonymous Coward on Thursday January 04 2018, @02:59PM (2 children)
buzz buzz TQM buzz buzz Quality Circle buzz buzz Kaizen buzz buzz Agile buzz buzz Lean buzz buzz Just In Time buzz buzz Scrum buzz buzz Flavor of the Month buzz buzz Six Sigma buzz buzz buzz buzz.........
(Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @03:12PM (1 child)
Death to all buzzwords. Use whatever the fuck works for you and don't give it witty names.
(Score: -1, Offtopic) by Anonymous Coward on Thursday January 04 2018, @06:29PM
Hey now, I also usually disagree with The Mighty Buzzword, but that's not a reason to wish him death.
... not that Buzzword?
... carry on.
(Score: 5, Insightful) by TheRaven on Thursday January 04 2018, @03:31PM (10 children)
sudo mod me up
(Score: 2, Disagree) by turgid on Thursday January 04 2018, @03:45PM (8 children)
Citation needed. I've gone from Agile to Waterfall and my productivity has dropped by at least half an order of magnitude. Much of the problem is the poor quality of the code resulting from lack of TDD and proper detailed analysis of the requirements.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @04:14PM
"my productivity has dropped by at least half an order of magnitude"
Protest too much much?
I didn't know Queen Gertrude was a coder.
(Score: 2) by bradley13 on Thursday January 04 2018, @05:17PM (1 child)
"I've gone from Agile to Waterfall and my productivity has dropped by at least half an order of magnitude. Much of the problem is the poor quality of the code resulting from lack of TDD and proper detailed analysis of the requirements."
There is nothing about waterfall that says you shouldn't have solid requirements. The opposite, in fact: waterfall is not good at adapting to change, which means that your requirements need to be very solid. So maybe it's the requirements that are the real problem?
Everyone is somebody else's weirdo.
(Score: 3, Insightful) by turgid on Thursday January 04 2018, @09:18PM
The problem with requirements is having good ones at all. Waterfall makes it practically impossible to get good requirements because it involves no discovery and feedback process and very limited scope for change either due to changing requirements or unforeseen issues (no one can plan 100% accurately up front otherwise I'd have won the lottery and know what the weather will be like in 10 years tomorrow at 2pm).
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @06:24PM (2 children)
TDD is not a property of either Agile or Waterfall. What you're basically saying is that software development is faster when the existing code is of proper quality, which is not really a shocking revelation and has little to do with the development process.
(Score: 2) by turgid on Thursday January 04 2018, @08:45PM (1 child)
Oh yes it is. It's one of the better tools in the Agile tool box.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @11:14PM
As the final delivered products of my work, you want working code and unit tests.
Don't micromanage my work process by mandating TDD which is *in my opinion* a piecemeal, hacky way to incorporate new code functionality.
If it works for you, great! If I prefer to design my code ahead of time as more of a complete entity and test the code paths mostly after I write it instead of in lots of little iterations of write/unit test
where I waste time rewriting unit tests as the code evolves, why shouldn't I be allowed? Are you going to sit in my lap and make me take turns typing by pair programming too?
(Score: 4, Insightful) by DeathMonkey on Thursday January 04 2018, @07:07PM (1 child)
It's called the Hawthorne Effect [wikipedia.org] and it isn't specific to IT.
Pretty much any procedure change will result in a short-term improvement, regardless of whether the change itself is any good.
(Score: 2) by TheRaven on Friday January 05 2018, @11:15AM
sudo mod me up
(Score: 2) by turgid on Thursday January 04 2018, @04:22PM
I worked at a place once where they made us move office when up against a very tight critical deadline for that very reason. Luckily the Good Lord saw fit to put 24 hours in a day and invented caffeine.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Informative) by Anonymous Coward on Thursday January 04 2018, @03:43PM (1 child)
Wow, the article links to Quora.com. Not a site known for its quality, well researched answers. I can't really say how good the answer is as the page is currently down...
Anyway, why not read the numerous research studies, case studies, papers, and textbooks on the subject instead of asking random people online? You'll learn so much more, such as Agile isn't from the consulting world (though they promote it like crazy like they do with whatever else is in fashion at the moment). The principles of agile date back to the very first software engineering conference. Go read it. In the IT world, everything old is new again over and over since everyone is too lazy to pay attention to history. The annoying part is the concepts seem to get worse and worse as they're copied over and over. The original ideas, such as actual OOP applied to the application level (not the bastardization everyone teaches today which applies it to source code) and LISP machines (where you could pause the entire computer and look at all active code, modify it in-place, then resume processing), are better than what we have today. Computing history is barely even taught in college. You get a couple figureheads and nothing more.
Except for TDD, everything is a form of waterfall or are you going to claim there's a formal methodology which produces the finished product before you write any code? You have to follow waterfall's steps else you're just banging on a keyboard or shipping vaporware (though some companies seem to be good at that).
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @11:23PM
The LISP and Smalltalk method of a "system image" is not a good fit for reliable build verification, deployment, or security.
Sounds like it makes software *development* more interactive, though. The system image model dates to when an application really took over the entire machine (or at least a user session).
(Score: 2) by bradley13 on Thursday January 04 2018, @04:05PM (2 children)
Other commenters have interesting views, some I agree with, some not so much. IMHO:
- The waterfall model works beautifully if you have a project where very, very few changes will occur during development. This almost always means a short project. Three months, at most six months.
- An iterative model works well whenever you expect to deal with changes during the course of development. How often you iterate depends on how much change you expect to deal with, and how your development team works best.
Given good developers and good management, everything else is window dressing. In particular, the term "agile" is just a new word for the ages-old concept of iterative development. Putting a new label on it is just marketing crap, because every new generation thinks it needs to re-invent the wheel.
TFA? Agile is a failure? Given bad developers or bad management - yes it is. Of course, any other development methodology would have failed as well, because the problem is the team, not the methodology. The one exception I see over-and-over-and-over again are government projects, where the government insists on waterfall development for large, complex, change-laden projects. This is why government projects fail.
I confess I haven't used Scrum. That said, as near as I can tell, Scrum is a method for managing projects where the customer doesn't know WTF they actually want, and wants to figure it out as the project progresses. There are very, very few projects where this ought to be the case. No, dear customer, your project isn't special, yes you do need to figure out your actual requirements and priorities before we start developing, in order to avoid wasting everyone's time.
Everyone is somebody else's weirdo.
(Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @08:13PM (1 child)
Actual scrum master here (yeah, did the training, did the exams, got the certs, actually ran scrum in the wild, when I moved on had people wishing I'd come back ...)
I'm also a waterfall project manager (trained, etc. etc. etc.)
You're mostly right, but for your last paragraph.
Waterfall is great when your specs are fixed, your timeline is well known, your dependencies are clear and so on. Classic case: building a house to a fixed floorplan (i.e. not clients and architects getting bright ideas when they're already painting rooms). As others have observed, this is not generally the case in the world of software.
Scrum is great when the goal is clear, and clearly articulable, but the actual way to get there has to be exploratory. This works pretty well for many software cases, where the client knows what they want to achieve, but is ignorant or uncaring on the implementation details. It also works well in other design and creative processes - I've seen it work well in one-off jobs like rapid prototyping of new widgets.
If you're hazy on where you're going, and hazy on how to get there, Scrum is a great way of spinning your wheels. It's the wrong tool for organisation of blue sky. Scrum is also the wrong tool for regular maintenance - you're probably better off with Kanban (among other approaches).
Scrum works, when it works, because it makes sure that coordination is close when a team needs a lot of communication to make sure that everyone is constantly up to date with each other's progress. It keeps the customers off the team's backs by funnelling them through the product owner, and delivers an assurance that the team aren't sitting around playing Counterstrike instead of doing something worth paying for. Scrum is bad when you have a group of specialists who can go off in their own worlds for six months and never see each other.
Oh, and if you're overworking your team, you're doing it wrong. Scrum is very explicit about maintaining a sustainable pace. That includes time for checking your email, having vacations, going on training, attending meetings so that HR fills their meeting quota - all that stuff. If your team is constantly exhausted, the scrum master is failing.
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @10:08PM
Assuming you have a fair idea of what you are trying to make,
If you are building a building or ship, figuring out the design before building is the way to go. The parts are for the most part defined and ripping out and replacing due to a design change is expensive. But this says little about waterfall for s/w.
Software adds a whole nuther level of complexity.
THe complexity of what is possible is much more and there are many more options because the parts are often defined as you go.
If the s/w problem is like one you know how to do, then waterfall (and almost anything else?) will work.
Else, if you have enough time to study the problem to death, then waterfall might work, but no guarantee. (F-35?)
Else, if you are not the military and can't spend that much time, then iterative seems more likely..
(Score: 4, Insightful) by Bobs on Thursday January 04 2018, @04:18PM
I have worked w both
I think Waterfall works best when you have a clearly defined and understood end product: building a bridge, laying track, constructing a building.
The product has been done before, everybody generally understands what a widget is, how to count them and what it looks like when they work / don’t work.
The reason why something like 80% of software projects fail w waterfall is people don’t fully understand the problem before they begin, so do a poor job of estimating effort required and when/if it has been built properly.
I have found agile processes generally work better for developing new software systems becuase it gets the customers more
involved to make sure what is being delivered actually does what is needed. (And does more than meet a checklist of requirements from high level execs or analysts made months before.)
But agile processes often struggle to scale well to bigger teams and projects.
Project management can be hard when you are doing something novel or big: there is no one perfect solution.
(Score: 4, Insightful) by bzipitidoo on Thursday January 04 2018, @04:37PM (2 children)
Agile is okay, if you have competent people, and a good environment. Having competent people is more important than the particular process. And by competent, I don't mean only rock star coders, I mean people who also have a bit of humility, enough that they can stand to be a "mere" follower and not The Leader. People who are, to employ another severely mangled buzz phrase, "team players".
The environment is critical. There's hardly any more toxic environment than Stack Ranking. That can push even the most saintly team members into plotting against the others. Anything that puts team members in cutthroat competition with each other is a team wrecker.
For the larger background environment, the US encourages vicious competition. A US citizen who loses a job is, by deliberate design, instantly faced with a crisis, wondering how to feed their children and pay the mortgage and the car payment and doctors' bills and so on. A lot of managers really believe that holding guns to people's heads inspires their best, think "team player" means someone who "shows commitment" by resting the foundation of their life on their job, so that if the job is lost, their life falls apart. People have committed suicide upon losing a critical job. It's like those legends of Mayan sports in which the two teams are driven to win at all costs because the losers will be sacrificed to the gods. They're going to accept broken bones and permanent damage to secure a win. They may beat themselves up too much to win the next game, but that's what it takes not to be sacrificed on the altar this time. Terrible though that vision is, it unfortunately is all too alluring to a lot of American management and even employees. There's a kind of sick fascination, a desire to see an ultimate cutthroat game. An American employer who doesn't want to put that kind of pressure on employees, actually understands that is counterproductive, has a rough time bucking the myriad ways the American system is set up to help employers whip, beat and subjugate workers.
It's very hard to avoid the toxic workplace, otherwise, no one would work there. So, the smarter employees keep a stash of money squirreled away. I've heard this referred to as "fuck you money", so you can tell your boss, "fuck you". Meantime, can fake that sort of desperate overcommitment for a short while. But the 3rd time in a row you don't put in unpaid overtime (unpaid because you are salary, you know), the slave driving boss is going to suspect you have too much liberty. And some are fool enough to rate lack of liberty as more important than proficiencies and skills.
With that sort of background environment, any development methodology is going to be mercilessly questioned.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @10:55AM (1 child)
As a non-American it's a bit shocking when you see it for the first time...
On a company message board we had a discussion about unrealistic timelines, overworked people etc., and I was suggesting that some people need to learn to say "not my problem". Management gives unrealistic timelines? "Not my problem". As an engineer, it can't be your job to fix up any and all of management's failings. That got fairly harsh comments from some people in the US, with comments like "you wouldn't and shouldn't get good reviews with an attitude like that" and "fear for your job is a great motivator" etc. Which I found also so utterly weird, because lack of motivation is not one of the top-10 problems I've seen at that company, aside of burnout-style issues at least...
It seems in the US it is not acceptable to say (even if worded more politely) "you messed this up, it is not my job to make unreasonable efforts to clean it up" to management. Well, maybe it's not really acceptable in Europe/Germany/Sweden as well, but at least I've been getting away with it and believe it leads to a more productive work environment long-term.
(Score: 2) by bzipitidoo on Friday January 05 2018, @04:57PM
Yes, America really believes in driving people. Some drive is good, but America pushes too hard. Had a boss once summon me to his office for a private talk, which sounded ominous. But I looked on the bright side. I thought things were going well. Maybe he wanted to praise me? Nope! He had 3 things to say. 1) He was "this close" (holding thumb and index finger a millimeter apart) to firing me because I was pushy and insubordinate, etc. Not one mention of whether I was getting work done and meeting targets, which I was. 2) He observed I had not bought a new car. Or a house. And that was Bad. Why? Because it meant I could afford to quit my job. Never mind whether I needed a new car or house. I was a "flight risk." ("Flight risk" is a phrase used to classify those prisoners who are likely to attempt to escape if sent outside the prison for whatever reason.) 3) And then seeing I was a teensy bit upset by then, he asked me if he needed to have all the passwords changed so I could not sabotage the company. I quit the next day, but not before I heard from all my coworkers that the boss had threatened every one of them with termination at one point or another. That was his way of motivating people to work harder and really it was no big deal. One of them called him on the threat, and yes, he was bluffing.
Even many employees endorse this "gun to the head" work environment. At another job that was in the midst of a nasty derailment on the way to becoming a train wreck, the only employee not in Trouble was the newest guy. He took a number of interesting steps to increase his job security. He bought a big house that he could not afford without that job, and told management all about his utter inability to feed his little baby girl and keep that house if he should lose the job. That was his way of letting them know they could rely on him. It was also a pity play, as in, make the bosses feel like total heels for even thinking of firing the poor bastard. The bosses would surely perceive that, and likely resent the crude attempt to manipulate their feelings. He was risking that they would value his utter financial dependence more than they'd resent his emotional manipulation, if they had uses for him. To me, he asserted that he was a better employee than me, because I didn't have a house and child, which meant I wasn't as driven. I didn't even try to tell him he was very wrong, just inwardly shook my head at his youthful folly.
It goes up the ladder too. I know my bosses were all being hammered by their bosses to do more. There's chronic suspicion that people could do more if they weren't being lazy, a sophistry that most people are by nature a bunch of unmotivated slackers who need constant prodding to be productive. If you aren't sweating blood, you aren't working hard enough.
In a sense, the US Civil War, over whether a slave driven economy is more productive than a free one, and WWII over whether fascism is more productive than democracy, is still being fought. The free economies won the wars decisively, already had a huge edge in population, resources, and productivity when the slave driver side started hostilities, yet lots of people still aren't completely convinced. It's the ancient East vs. West conflict that goes back before Islam and Christianity, when it was Greeks vs Persians. The Greeks were the democrats and the Persians were the authoritarians. The Persians had far more resources, yet they lost. Rome vs Carthage was another clash of that sort, testing whether mercenarism was stronger than nationalism. Really sad to see the winners forget or dismiss those reasons for why they won and cotton to so much of the losing sides' thinking.
(Score: 1, Interesting) by Anonymous Coward on Thursday January 04 2018, @05:12PM
The author seems a bit over grumpy. Let me try to respin this issue and see what comes out.
First, to make a complicated system, one has to have a specific goal in mind. The question here is how to build it. I have no clue how to do a random walk in search of something useful. You can adjust the goal along the way, but to do something everybody has to understand how their work is pulling the whole thing in a specific direction. That implys the existance of an overall specific direction. This is a marketing/engineering question about what you are trying to make. The design process is about how to make it.
Note that separating what and how is near impossible for anything interesting. Making a competitive product requires that the what is pushing against what is possible in the how category. This makes setting the overall goal interesting to say the least. But this is about the how of making the thing.
Next, It takes both top down and bottom up design to do anything complicated. Nobody is smart enough to do a real waterfall on something hard without screwing up a bit. So you have to be willing to try your best at picking a good direction but be willing to adjust course when better paths are available/necessary. Sooner is better in these adjustments. Being able to to this as an organization means that there has to be a clear visability as to how a specific little architectural oops at a low level can ripple up to the whole system and need to cause a major system level course adjustment.
As an aside, 'top down design' might be a very useful concept as a way to describe the design of a completed system that has gone through the above sausage making. If the result can be explained in such a consistent manner, then maybe the system is one that can reliable and maintained?
Next, there are good reasons to show incremental progress in the above process if the increments are clearly moving towards the end goal. The show should be interesting to all, including especially folks thinking about what we are making. Any development plan needs to provide externally visible milestones to show that it is moving forward. Most low level scrum steps are unlikely to be these demonstrations. But everybody should have a clear picture of how and why the steps combine to get to the milestone.
So to do this, how could agile/scrum fit in a a way to help coordinate the work?
Well first, given a goal, figuring out how to break it down and architect a solution path are among the most important tasks. The folks with the most interest in this are the folks that will do the work. So the first stories should be to make a development plan which would include the rest of the stories. If these stories are being thrown over a wall to a group of junior implementers, then you are using scrum to drive towards failure. The is because it prevents a feeling of ownership and understanding as to how their part fits into the overall goal. It leads to status meeting where everybody is not blocked, but nobody has a clear understanding of what has to happen to get to the next or final milestone. This creates little enthusiasm to get 'er done.
Next, folks have skills, or at least the organization should try to make it so. This means developing groups with expertise in useful core compentencies IE things you can sell. Using agile as a way to move plug compatible folks around to fight fires defeats this. This says that the architecture of the thing you are building needs to be reflected in the architecture of the folks. Hopefully, the pieces in your system are reusable, so the groups of folks supporting each piece can stay together and get good at what they do. This is the way to get better at doing things than others. If the thing is sellable, then this is how you get and stay competitive.
One useful skill is systems design, which is can the the guys throwing the design over the wall. On the other hand each team can not be expected to focus on the whole system. You need an interactive balance between one group holding responsibility for how the overall system fits together and how each of the pieces is built. If scrum and agile is used here, the needs to be a lot of continuous communications between teams in this area. Also, I suspect this system design team should be the system integrator. (Kind of eat your own dog food to keep you calibrated.)
If top down sometimes screws up, then agile is supposed to be there to quickly catch this and adapt. If you are going to status meeting and everything is moving along smoothly and the stories are not changing then either the project is really simple, or you may be heading for a slow motion train wreck.
Probably lots of other issues in how to apply this agile stuff to making complex systems?
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @06:04PM (6 children)
It gives you the insight into what's "really happening" that scrum does, but without the need to reject the entire concept of design. You can let people work on things they're actually good at, and apply your design efforts to things that actually need them. The premise is simply to do things when they're needed, neither before nor after, and keep track of which things are getting done at the wrong speed. The . It's a lot like scrum, if you just left out the arbitrary deadlines and insisting on putting square pegs in round holes.
This last one is especially infuriating.
"This sprint we're doing the Javascript front-end."
"I don't know anything about Javascript. I write server code"
"Too bad"
Four weeks later, this happens to someone else...
"This sprint we're optimizing the database performance"
"I don't know anything about databases. I'm a Javascript developer"
"Too bad"
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @06:07PM
If I'd used Kanban to write that post, I would have caught the typo!
(Score: 2) by Nerdfest on Thursday January 04 2018, @06:08PM (3 children)
I have trouble believing that. I have never seen anyone do anything that stupid, and I've done a lot of government work.
(Score: 0, Disagree) by Anonymous Coward on Friday January 05 2018, @12:48AM (2 children)
Well, the government uses waterfall, or at least that's their reputation. So they wouldn't have fallen into that particular trap.
But it's baked right into the agile manifesto. Developers are fungible. Anyone must be able to work on any code at any time. It's central to the premise and it means that exactly this doesn't just happen, it's actually the goal.
Scrum is largely about observing that there is a wide variation in developer productivity, and eliminating that by bringing everyone down to the lowest level. Good for managers who don't want to have to make sensible hiring decisions and who mentally translate "software developer" into "anomalously well-paid peon." Bad for actually writing software.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @11:00AM
I don't think that goal is bad. Nurturing a broad, overall understanding of the product in as many people as reasonable is a rather good goal I think.
The mistake is just to think that things will be done equally fast and good no matter who writes the code... And in some cases that difference is probably enough that you don't want to swap things around.
Still, if you skip that kind of thing, you should still have some mechanism to ensure that you do not end up with parts that only one person in the whole team has any clue about, that kind of risk is NOT good to take.
(Score: 2) by Nerdfest on Friday January 05 2018, @07:29PM
That is not part of the agile manifesto [agilemanifesto.org] that I can see.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @12:52AM
I have used a few different ones.
SCRUMM/Agile is good for continuous projects where the work is small and can be broken into small bits. Ones that fit into your sprint. It also works where requirements are not really known up front but you have a decent idea what has to happen. Your velocity is more important. Planning for people to actually go on vacation how much you can actually do, etc.
Kanban works very well for where you may have small things to do but your externialities are not up to your sprint speed. It works very well for things where you have to wait. Your cycle time is more important.
Both of these are very nice for keeping management up to speed on what is going on. As most things are actionable.
Waterfall works very well if you can get most things nailed down up front. For software projects that is rarely the case. It works very well if you have done the thing 20 times and you have most everything mapped out already. Hitting your milestones is more important.
Waterfall takes a very good PM. One who can see when things are breaking and what to sacrifice to make the timeline.
All 3 take discipline. If you skip steps you will find they all go off the rails quickly and fail. All of the 'process' that people hate is there for a reason.
(Score: 3, Interesting) by anotherblackhat on Thursday January 04 2018, @09:16PM (1 child)
When I think of projects that went badly, I think of things like "the manager didn't believe the numbers he was told", or "now that we know the deadline won't be met, why aren't we cutting features?", or "last time it took 14 months to do half as much, what idiot thought we could get twice as much done in half the time?". I don't think "it must have been the scheduling process" or "we needed more micro-management".
Agile, waterfall, sticky-picky, walk-about, or just shouting "get to work you lazy bastards" all work about the same.
Sure, there are differences, but how you think about the work isn't nearly as important as actually doing the work.
No matter how many progress reports you file, or development meeting you attend, the egg is still going to take 3 minutes to cook.
Demanding a detailed schedule isn't going to improve things, it's just going to annoy the cook.
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @10:19PM
'the egg is still going to take 3 minutes to cook.'
Not necessarily, if you have no sense of direction, it might take 6.
(Score: 1) by mobydisk on Thursday January 04 2018, @09:55PM (3 children)
Having done Waterfall and Scrum:
Scrum seems great for web projects. Things with rapid releases and short-to-medium term goals (weeks to months).
Waterfall is great for engineering projects. Things with long release cycles and long-term goals (years). It is good for tracking to a long-term financial goal.
I do not recommend Agile for medical devices or aerospace projects.
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @11:39PM (2 children)
Agile is best suited to work where the cost of mistakes is low and the customer is cool with fixes being pushed out all the time in little bits rather than taking the time to do a real design and carefully validate the code on a release cadence that isn't every 2 weeks.
The minimum viable product idea is really a minimum quality of product idea, i.e. "half-baked."
I wish we could send this one back to the start up world it came from.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @11:10AM (1 child)
"minimum viable product" addresses the madness of "oh, lets have 20 teams working on their own thing and then 1 month before the deadline we'll throw it all together".
The latter has been done quite often, and I don't think it EVER worked.
It embodies the principle of "you don't work on something for 6 months and then start checking if it actually WORKS, in a WHOLE-SYSTEM CONTEXT".
If it is "minimum quality" then at most in the sense of "better minimum quality than something that does not work AT ALL and you find out right before the deadline".
And agile isn't meant to prevent you to do release branches, stability/testing focus sprints etc. It just means it's not ok to have your project in an utterly broken, unusable and (full-system) untestable mess of a state for more than 2 weeks. Which ought to be common sense, but unfortunately is not.
(Score: 0) by Anonymous Coward on Friday January 05 2018, @02:52PM
'agile isn't meant to prevent you to do release branches, stability/testing focus sprints etc'
Of course not, Agile should facilitate that.
Those releases leading to a better and better whole working thing give focus to the team.
They should be why the sprints are there.