Ask HN: Does Agile dev inherently produce more-buggy, less-stable software? | Hacker News Reader

Ask HN: Does Agile dev inherently produce more-buggy, less-stable software?

5 pointsreadonthegoapp10 comments

I always took this to be obvious, but I think I saw what might count as an admission in this AWS Devops Training slide text:

"Developers change things quickly, release often, and measure success by the rate of delivery. Operations are driven by maintaining stability of the application. Frequent releases are a cause for concern of the stability and reliability of the application on the supported platforms, especially during high network traffic."

Another bit of text later on seems to have a typo -- i.e. a bug -- which is just funny:

"With DevOps, you can quickly while retaining control and preserving compliance. Use automated compliance policies, fine-grained controls, and configuration management techniques. Monitor for security incidents and adjust your configurations and software as needed. For example, using policy as code you can define and then track compliance at scale."

It's mainly interesting to me because, of the 18Z pro-Agile articles and the 19Z anti-Agile articles I've read, none seemed to talk about this aspect of Agile -- end product reliability.

Granted, this AWS course is about 'Devops' -- its culture and processes and tools -- not 'Agile' -- but Devops, to me, is driven by Agile, CI/CD, etc.

If it is true that Agile leads to, or can lead to, or has a higher risk of leading to, less reliable software, then I would like to see some more truth in advertising going forward.

And, if there is a way to Sprint but still maintain or even increase the reliability of the end product (over/instead of a non-Agile dev process), I'd like to know what those techniques/safeties are.

Agility has nothing to do with software quality.

Remember project management triangle: time, scope, quality.

The more time you put into development or testing, the less bugs you may find.

The less scopes you push into the application, the less bugs you may get.

In agile, you need to decide the least scope with the least time to develop an acceptable quality of working product. New changes introduce a new complexity to the software, and devs need time to formulate the right complexity. You need to make a balance between time or scope, or the complexity of the software will produce either less testable or less readable codes, which leads to more buggy app.

If the agile approach seemed to be cause of it, then the agile process must have been conducted improperly.

Yes, Agile does produce more buggy, less stable software. There is heavy bias towards doing only simplistic, user-visible things that fit in the span of two weeks. So all the foundational stuff you need to put in at the start of the project to let you support features while reliably turning direction on a dime? Can’t put it in there.

I’ve seen many agile shops fail to ever get CI/CD working because the effort just couldn’t find a place and a schedule on the backlog.

The cause of the worst, most frequent, and recurring bugs is from having a poorly conceptualized or structured implementation. After a product has been built this way it is very difficult and error-prone to change it into something more suitable.

Now if you imagine a waterfall project that delivers the entire feature-complete v1.0 product, I can imagine that this is much more likely given that real-world volume testing happens after shipping/launching it.

With a product that evolves with its user base, acquiring features as users gain experience to demand it, all the while being used and exercised by the user base, it will also have bugs along the way, but there may be many more opportunities for course corrections that are achievable without a full rewrite.

There's is also every combination in-between and what makes sense depends on the specific subject area and users.

Regardless of which approach one takes, quality/lack-of-bugs depends on making it a priority and sufficient investment. i.e. it is not only/predominantly based on process, it's in the details.

I think most of the shops drinking the Agile Kool-Aid are following TDD or at least doing lots of testing. You're probably not shipping a DVD to Staples or whatever so a bug won't destroy your business like it used to. There is a bigger risk of creating vaporware. I think it makes sense to release a minimum viable turd and have it get more stable as the project matures.

The question is a little off target in that software development can be agile with either traditional QA phases or with more recent approaches like CI/CD.

CI/CD seem to fit Agile better because you do not get a discontinuity of how a project is managed. But that by itself does not tell you if CI/CD is better or worse than QA phases of alpha and beta and a traditional test plan based on a functional spec.

The CI/CD advantage is that you do not need a comprehensive test plan to start, and you start testing early. The disadvantage is that if what you have by the time you decide to ship does not cover both implementation and features you do not have test coverage, with the predictable problems.

TDD and/or FDD can help you track whether you have test coverage. But if you do not have coverage, and you do not have regression testing, deploying will be painful, whether it is continuous or not.

In my experience frequent deployments increase system reliability and stability because those teams are decreasing mean time to recovery, leverage more automated testing, have better monitoring, and have less manual/error-prone processes.

Depends on how you practice it.

XP practices, in my experience, do lead to high technical quality.

High stakeholder interaction and feedback tends to lead to improved fitness-for-purpose.

Many teams professing to be “Agile” don’t do either of these things.

You seem a little confused. A DevOps culture can help to be agile. But then, Sprints are nothing to do with agile.

No, but it can certainly help. ;-)

Devops has nothing to do with Agile. You missed the point badly.

Reply on news.ycombinator.com