Why Agile Sucks for Building Quality Software

>There is a misconception among Agile proponents that the more upfront design there is, the harder it will be to make changes. That once you put something in the design, then it becomes hard to change.

The point is that design decisions become better the later you leave committing to them because the later you leave it the more information you can accrue to determine the correct shape of the design.

This isnt just about writing code based upon design decisions but also whether when you write the code whether you double down on a previously made light touch design decision.

There are hundreds of microdecisions needed every day like this and I see "up front first" people double down prematurely and dig themselves into holes unnecessarily constantly.

It isnt really about "when you make the decision" because yes, decisions made today can be cheaply reversed tomorrow if you havent actually done anything with them. It's entirely about whether it's possible to defer commitment to a decision and still achieve your intended goals.

It took me a long time to finally figure this out for myself. My final "aha" moment was that iterative design and product development is really about recognizing that when you are building 99% of software projects, the future is shockingly chaotic, unknowable and surprising and that deferring design commitments actually helps deal with that. You're not building a house or planting crops.

Most bad designs aren't bad for the future that was envisioned, it's just that the future that was envisioned never came to be.

Unfortunately agile is vague as hell and was designed more as a pseudo religion to sell billable consulting hours so it says useless things like "defer design decisions as late as possible" without being explicit about what counts as "a design decision" or what counts as "as late as possible" and the side effect of that is that, like religion, we have to endlessly argue about divergent interpretations.

This person's base premise is wrong. Agile can help you build software that has high quality. I know that it isn't always used in a way that can improve quality and, yet, many of the engineering practices (that are often ignored) are quality practices such as pair programming, unit testing, CI, test automation, etc.

Sure many agile implementations don't use quality practices and lead to low quality, that doesn't mean those don't exist in agile. The same can be said of all software development methods, if you ignore quality practices, quality will suffer.

All software development has to start with the people doing the work.

In previous "versions" of SAFe there was a dedicated HIP-Sprint (Hardening, Innovation, Planning) that you would do every couple of sprints. It worked well in the Project I was on, we would basically alltogether work on refactorings, identifying and removing TechDebt, increase test coverage etc. Even evaluating new concepts and libraries to see if they would benefit the existing codebase. There was no expectation from Management/PO to deliver new features. I always wondered why that didnt get more drag and even was removed from more recent SAFe incarnations.

>> Rewarding continuous delivery of software without penalizing rework or refactoring creates no incentive for anyone to produce maintainable software.

Rework and refactoring are where the quality gets put back, after technical debt was incurred earlier in the project.

What exactly is the alternative? This reads like a criticism of capitalism. If there is a better way, prove it.