Hacker News Reader

Comment by PaulHoule | Hacker News Reader

That's a refutation of agile, Vibe Coding and the last 25 years of the software industry.

One of my own quality metrics that almost everyone rejects is a "a good design is a design where a change that seems like a small change to management is... a small change"

It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20. The rare team that is looking ahead 20 steps is the one that survives.

View on HN

>It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20.

It not being "exhausted" is just what distinguishes a good programmer from a bad one. If you're good you can keep a lid on tech debt in the face of rapidly changing requirements. If you suck at it, well... you can't.

>The rare team that is looking ahead 20 steps is the one that survives.

lol no good software engineering means assuming that you don't have a crystal ball (because you never will) and building accordingly.

This usually means YAGNI, minimizing up front design and refactoring aggressively. These are the things that keep you agile enough to move in many different potential directions in response to different potential futures.

The time when this really got rammed home for me was working on a startup where a political black swan event ended up changing key requirements of our software overnight. This pulled the optimal architecture in a wildly different direction to where we anticipated it was going in the previous week.

> If you're good you can keep a lid on tech debt in the face of rapidly changing requirements. If you suck at it, well... you can't.

Every drop of tech debt (aside from AI slop) I have ever been a part of has manifested simply because some manager or executive made the decision to sacrifice quality for short-term speed. Sometimes this looks like an unskilled developers producing something that management won't let you fix. Sometimes it's a completely unrealistic deadline that requires extreme measures to meet. If you are able to keep a lid on tech debug in the face of rapidly changing requirements, it likely means that you have enough slack in your job to do so.

Asking permission to fix tech debt is a rookie mistake. You need to bake the fixes into the ticket.

Half of my job as a lead is to cajole, threaten and convince juniors into spending 5 days on a ticket to do it properly rather than spending 2 in order to get brownie points for "looking" productive.

Ive had more than one call where the junior says "we don't have time for that" and I have to call in the PM to let them know that it's OK, we do.

There are environments where management put so much pressure on you that you can't help but deliver crap but not everywhere has to be like that.

The problem is that you don't know in advance what the 20 steps will be, and you may spend time solving the wrong problem.

Make step 1 as simple as possible, step 1 is small and changes are cheap, you can even rewrite everything with little effort, no need to prepare for anything at this point.

Step 2-4 will inevitably break something, no big deal, rewrite the parts that need to be rewritten, it is still cheap.

At step 5 rewrites are starting to get costly, but now you have a better idea of what is here to stay, so it is now time to invest in things like regression testing, style guides, etc...

At step 10, you have quite a history, rewrites become a really bad idea, no turning back after that. So now it is time to think about the future. The difference from doing that in step 1 is that you now have 10 steps of experience and only need to look ahead 10 steps.

Nope not true at all (30+ years of experience here working on very large scale software).

The whole point of being agile is to design your software architecture to be agile. That's what I do. And it works.

Reply on news.ycombinator.com