3 ms·

> 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

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

hinkley 4y ago
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.
- doctor_eval 4y ago
  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.
  - hinkley 4y ago
    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.
- adql 4y ago
  But the later you design something the more info at hand you have to make the design fit better.
  - hinkley 4y ago
    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.
    - doctor_eval 4y ago
      > 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.
dendrite9 4y ago
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-westheimer-major-figure-in-20th-century-chemistry-dies-at-95/ https://news.harvard.edu/gazette/story/2007/04/frank-h-westh...
- hinkley 4y ago
  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?
lostcolony 4y ago
"YAGNI, but plan to be wrong"
MikeDelta 4y ago
It's definitely on HN, found the quote on the following page: https://news.ycombinator.com/item?id=12001925 https://news.ycombinator.com/item?id=12001925 Not sure what the actual source is.

hinkley 4y ago

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.

doctor_eval 4y ago
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.
- hinkley 4y ago
  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.
adql 4y ago
But the later you design something the more info at hand you have to make the design fit better.
- hinkley 4y ago
  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.
  - doctor_eval 4y ago
    > 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.

dendrite9 4y ago

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-westheimer-major-figure-in-20th-century-chemistry-dies-at-95/ https://news.harvard.edu/gazette/story/2007/04/frank-h-westh...

hinkley 4y ago
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?

lostcolony 4y ago

"YAGNI, but plan to be wrong"

MikeDelta 4y ago

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