The design decisions get made either way

Nobody wants to work somewhere every small technical decision goes through three boards. That isn’t the argument.

Everyone who touches the application is making design decisions whatever process you run and the only thing that changes between one process and another is when those decisions happen and who gets to see them. In the old style they were made before the code was written and written down somewhere you could argue with. In the agile style they’re made after the code is written, by whoever wrote it, at the moment they wrote it.

Most of the time that’s fine for you and for everyone downstream of you. Developers are generally good at their work and they make decent decisions under time pressure and a decision made by the person holding the problem is often better than one made by a committee holding a document. That’s the real case for working the newer way and it’s a strong one.

Sometimes they get it wrong, though, and when they do you get code design problems that nobody spotted because there was no point in the process where spotting them was anyone’s job. The same gap is why automated tests so often miss cases that a decent QA engineer would have written without thinking about it. The tests cover what the developer imagined while building the thing which is exactly the set of cases they had already handled.

An enormous amount of the code in the applications you rely on every day was never designed at all. Nobody thought it through and nobody considered the edge cases because the feature was thrown together in a week and it sort of works. Every time you hit a broken website, or a bug in production, or something slow that has no business being slow, the explanation underneath is usually that the people who built it didn’t take the time to think about what they were building, and in the worse companies they weren’t given the time to take.

A lot of developers genuinely prefer working that way and I understand why. You get to hack on something, get it moving, and be onto the next problem before the first one has had a chance to bore you. That’s fun. Careful work often isn’t. Pretending otherwise is dishonest.

It’s also worse for users, and users are the people I care about more. I say that as somebody who has been making things for the web for close to twenty five years and who enjoys the hacking as much as anyone. The satisfaction of the person building the thing and the experience of the person using it are different quantities, and when a process optimises hard for the first one it tends to be quietly paid for by the second.

None of this is an argument for going back to Prince2 and waterfall, and my tolerance for that sort of bureaucracy is no higher than yours. The claim is narrower. Things have gone a long way in one direction and a good number of developers would produce better work if they spent longer thinking about what they were about to build before leaping into the first solution that would satisfy the acceptance criteria somebody in product wrote down.

That’s not a process change and it doesn’t need a board. It’s an hour with a pen, before you open the editor, on the parts of the problem where being wrong is expensive.

The reason this is hard to fix from inside a team is that the cost never lands where the decision was made. A feature shipped in a week with three unconsidered edge cases looks like a success on the day it goes out and turns into four support tickets a month for the next two years, handled by different people who have no idea the two things are connected.

Nobody is being lazy. The feedback loop is just long enough that the person who could have prevented it never finds out they didn’t.