Tuesday, July 28, 2015
Agile Development Process & Unreasonable Pressures on Developers
Part of why I am writing my own gCode to run the CNC mill is that AutoDesk's Fusion 360 product, as cool as it is does not work reliably. Lots of hangs, and not just for me. I have noticede in the last few years a very dramatic reduction in the reliability of commercial software, and I blame it on two related factors: Agile development and pressure to ghet out new releases too quickly. These are connected issues. I like the theory of Agile development, and it has some real advantages over traditional waterfall software development. The downside is that it encourages putting out new releases so often that there isn't time to gather failure reports from users and get everything fixed before the next release. The greed of the industry sees Agile as a method for pressuring more frequent releases, new features, etc. The fact is that Thunderbird is up to release 38, with some problems, at least under Windows. More pressure to get out new releases means pressure on developers to get something out the door, and the results are often not pretty.
Subscribe to:
Post Comments (Atom)
I agree completely. I've been in the software development biz since before Agile was even dreamed of, and have worked under both Agile and waterfall (or spiral) paradigms. I've also complained that applications developed under Agile are more bug prone, and I've theorized that it's because the rigor of developing a formal requirements document and detailed design document, along with a requirements traceability matrix, has been done away with in the name of speed and "responsiveness." All the Agile places I've worked at, save one, don't even have any dedicated testing staff; they just expect the devs to do it, in their copious spare time at the end of each sprint. (Yes, that was sarcasm.) In all the companies where I've worked for the last 15 years, I was the only person who knew how to write a comprehensive software test plan.
ReplyDeleteI'm all for innovation and progress, but not at the cost of quality that reflects on my entire industry.
So this isn't my imagination. Not that it much matters; I'm too old to be employed now, even if I were well.
ReplyDeleteI worked in the agile environment for a few years, and it sucked - at least the way it was implemented by my employer.
ReplyDeleteAgile and the tools used seemed to focus on visible minutae rather than any big picture. We had critical infrastructural items that were just ignored, time after time. The tool broke everything down into little tasks (I have, thankfully, forgotten the nomenclature) - independent little tasks.
The real world doesn't work that way.
I suspect agile was initially pushed by web site developers, who had nothing in their system but a zillion pages, each with a bunch of buttons and menus, etc, with the architecture and serious work done by someone else.
I've seen Agile (then called XP) work extremely well - once.
ReplyDeleteIt was for a website development project, which might not be a coincidence.
What made it work, in my opinion, was the management's buy-in to actually writing the damn unit tests up front. Not tacked-on at the end of a sprint, but actually done daily. Which meant we had a working automated regression test running every day.
That was awesome.
When you call it "Agile" and just crank up the pressure to rush releases... yeah, not so good.
peace,
Zach