4 ms·

Why Agile Sucks for Building Quality Software

12 points by pelasaco 5y ago

Flankk 5y ago
What exactly is the alternative? This reads like a criticism of capitalism. If there is a better way, prove it.
- pelasaco 5y ago
  I think what he wanted to criticize here was the following: "Agile consultants don’t build software. Their job is to sell training. Software architects and developers have the job of building software. It’s similar to the difference between a film critic and a filmmaker. If you had to make a movie, whose advice would you follow? It’s the same with software. Agile consultants cannot tell you the best way to efficiently build maintainable software because they don’t actually build software. For that, you need a Software Architect." I personally am extremely annoyed by pseudo-psychology used to justify games and interactions on Retrospective meetings.. I worked in a project that we had to draw every Friday afternoon 30 minutes together something about our feelings...
  - icedchai 5y ago
    When they ask the team if there’s anything you want to stop doing during the retrospective, mention “this.” It’ll get some laughs at least. Many, many people hate these agile “rituals”, but few are willing to complain about it. We need to end this nonsense.
  - pydry 5y ago
    I always found that without retrospectives persistent, recurring and systemic problems that the team could easily solve would not be addressed until somebody got hopping mad. There's always something else to do. Retros are often useless though, especially in environments where people feel awkward about speaking their mind. They also have a tendency to degenerate into whinge sessions about things the team has little to no control over. Other than being a bit cathartic this is usually pretty useless.
pydry 5y ago
>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.
gfykvfyxgc 5y ago
>> 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.
littlecranky67 5y ago
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.
- krono 5y ago
  I've always found these sort of sprints to be immensely valuable too. My theory for their disappearance is that most managers failed to properly measure their effectiveness. Edit: Many times I've seen this fail was caused by not having proper processes in place for the type of work done during these sprints - letting them turn into a free-for-all and ending up with two weeks wasted rather than 8 weeks gained.
  - littlecranky67 5y ago
    One of the problems in our fields, managers are not developers themselves. I mean I would say I could asses progress of a software project in a HIP sprint by looking at the code, hearing out the developers etc what they changed and how it benefits. But if you have no clue of software development what soever, you fail to do it. It is something I only noticed in our field, in other fields (i.e. mechnial or structural engineering) usually it is the engineers who get promoted to management over time.
lasereyes136 5y ago
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.

12 points by pelasaco 5y ago

Flankk 5y ago

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

pelasaco 5y ago
I think what he wanted to criticize here was the following: "Agile consultants don’t build software. Their job is to sell training. Software architects and developers have the job of building software. It’s similar to the difference between a film critic and a filmmaker. If you had to make a movie, whose advice would you follow? It’s the same with software. Agile consultants cannot tell you the best way to efficiently build maintainable software because they don’t actually build software. For that, you need a Software Architect." I personally am extremely annoyed by pseudo-psychology used to justify games and interactions on Retrospective meetings.. I worked in a project that we had to draw every Friday afternoon 30 minutes together something about our feelings...
- icedchai 5y ago
  When they ask the team if there’s anything you want to stop doing during the retrospective, mention “this.” It’ll get some laughs at least. Many, many people hate these agile “rituals”, but few are willing to complain about it. We need to end this nonsense.
- pydry 5y ago
  I always found that without retrospectives persistent, recurring and systemic problems that the team could easily solve would not be addressed until somebody got hopping mad. There's always something else to do. Retros are often useless though, especially in environments where people feel awkward about speaking their mind. They also have a tendency to degenerate into whinge sessions about things the team has little to no control over. Other than being a bit cathartic this is usually pretty useless.

pydry 5y ago

>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.

gfykvfyxgc 5y ago

>> 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.

littlecranky67 5y ago

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.

krono 5y ago
I've always found these sort of sprints to be immensely valuable too. My theory for their disappearance is that most managers failed to properly measure their effectiveness. Edit: Many times I've seen this fail was caused by not having proper processes in place for the type of work done during these sprints - letting them turn into a free-for-all and ending up with two weeks wasted rather than 8 weeks gained.
- littlecranky67 5y ago
  One of the problems in our fields, managers are not developers themselves. I mean I would say I could asses progress of a software project in a HIP sprint by looking at the code, hearing out the developers etc what they changed and how it benefits. But if you have no clue of software development what soever, you fail to do it. It is something I only noticed in our field, in other fields (i.e. mechnial or structural engineering) usually it is the engineers who get promoted to management over time.

lasereyes136 5y ago

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.