Comment by doctor_eval | Hacker News Reader

Comment by doctor_eval | Hacker News Reader

Parent Full thread

> There’s a subtle difference between not adding unnecessary structure and writing code that is antagonistic to it being added later

This is such a wonderfully concise way of describing something that I try to teach people.

I have come to use the phrase "no regrets". Leave things out, but do it in a way that you won't regret it, if you need to add it later.

Another phrase that I read somewhere else was, "Weeks of programming can save you hours of planning" (pretty sure I read it on HN, and I wish I had kept the link). The point being that when you decide to leave something out, or when you decide to intentionally do a half-assed job of something, you should still think about how someone in the future would go about efficiently fixing it.

If you do it right, there's missing functionality, but little or no technical debt. If you do it wrong, you miss out on functionality and also take on technical debt. And I think that's the subtlety that you speak of.

Most people who push for early design understand that they have more control of the project at the beginning, before deadlines accelerate, before a bunch of bad hires and competing priorities. And they are definitely speaking from a place of regrets. This hurt so much last time I vowed never again.

There’s a list of things I won’t try to add on later. It’s smaller than it used to be, but the shiv I brandish at you for suggesting we cut those corners is also much scarier.

But the later you design something the more info at hand you have to make the design fit better.

Bingo.

Jim Highsmith has the best theory I’ve heard in the subject. His opinion is that the reason we keeps having the same unwinnable arguments is because we think in terms of solving problems but the real issue in front of us is resolving paradoxes. There are no neat answers that fit in a short essay box on the test everything depends, and everything depends on everything, and something is always changing.

What the PTSD reactions come from is other people making decisions on behalf of the rest of the team without consent. But like most things in software it’s a 2 dimensional problem not a 1 dimensional one. The trick is to delay irreversible decisions as long as possible and get all responsible parties involved.

The flip side of the coin is that reversible decisions should be made as cheaply as possible. For instance my “Kobayashi Maru” solution to the bike shedding problem is that the team should have budgeted three colors of paint into the bike shed budget, picked green for the first coat, and moved on immediately. That $200 is far cheaper than the time and importantly energy that would go into discussing this at a meeting with senior staff members present. If you start thinking about all of the $5000 conversations you have to solve $2000 problems it’ll drive you mad. I almost recommend you don’t look at it, for your own safety. Almost.

> The trick is to delay irreversible decisions as long as possible and get all responsible parties involved

This is exactly right, but the irreversible decisions are often horizontal slices of software design that underlie other decisions - thing like authz, IPC, API design etc. If these questions can be identified and resolved up front, the cost of building vertical slices - features - goes way down. You're not tempted to reinvent the wheel, you can focus on the business logic.

What I'm saying is: it's worth spending time planning the foundations of a product. That includes the technology choices, but also the high level logical layout of the whole product. If you approach this foundational stuff like any other project, then if you're doing it right, you'll "get all responsible parties involved", like you should.

But defer the detailed planning of domain logic until you're actually ready to write it, and remain flexible with the plans you do make. "Plans are nothing; planning is everything".

Because like the GP said,

> the later you design something the more info at hand you have to make the design fit better

I find it remarkable how often engineers just leap in and start coding, and worry about the foundations later. Or never. I suspect this is one reason why rewrites are so common. If you start with bad foundations, it's often easier to blow up the whole building and start again.

> I find it remarkable how often engineers just leap in and start coding, and worry about the foundations later. Or never. I suspect this is one reason why rewrites are so common. If you start with bad foundations, it's often easier to blow up the whole building and start again.

To be fair, leaping in and starting coding allows you to discover the problem better. The problems start where you get stuck with your initial design and don't adjust/remake it once you explored some ideas, maybe found some new along the way and found out what doesn't fit.

That is of course problematic if you have deadline driven development because rewriting last 2 weeks of code might seem like total waste even if then-better design gonna save you much more even in near feature.

Not rewriting code when design flaws appear will lead to rewriting it eventually later and more expensive.

Of course, all of that depends on how much you know about domain and the problem. Exploring existing solutions and their flaws or having really detailed requirements might be much better approach that doesn't require starting to write code.

Yes, 100%.

Some things you can cut corners and save time.

Some things, when you cut the corners off you also cut your fingers off.

We have all promised that we will “fix it later”. But whatever we do now is what’s done. Fixing it later is a promise whose resolution is often not in our control.

I suspect this dynamic is a big part of why Joel Spolsky jokes about transforming from a technical leader into an amateur psychologist. We are all lying to ourselves first and to others second.

Or as Feynman said, the trick is not to fool yourself, and you’re the easiest person to fool.

Or a personal favorite, unattributed: I know the guy who made this plan [me] and he’s full of shit.

I believe that quote is thought to have come from Frank Westheimer or at least he is associated with an earlier version of it. “Why spend a day in the library when you can learn the same thing by working in the laboratory for a month?”

https://news.harvard.edu/gazette/story/2007/04/frank-h-westh...

I’m quite fond of a version of this somewhat popular in Ops circles: why spend an hour doing a task that you can spend a week automating?

It's definitely on HN, found the quote on the following page: https://news.ycombinator.com/item?id=12001925

Not sure what the actual source is.

"YAGNI, but plan to be wrong"

Reply on news.ycombinator.com