3 ms·

I would also like to add one more thing: hesitation. From my own experience, in my programming career, the most time my team wasted was on redoing something fro

I would also like to add one more thing: hesitation. From my own experience, in my programming career, the most time my team wasted was on redoing something from scratch. Why redo it? Because the previous design was not comprehensive enough to meet subsequent requirements. If everyone could spend more time researching and discussing the plan before starting, and get things right in one go, in my view, this is much more effective than rushing into development work.

leetrout 3y ago
Hindsight / survivorship bias affects this viewpoint. You will never get it "right" the first time as much as you can avoid doing it "very wrong". The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains. Then you can refactor easier which should be the real goal. Prune and tend to the garden.
- AnimalMuppet 3y ago
  Yeah. It's easier to not do something stupid than it is to do something smart. Take the time to avoid doing stupid things (which takes somewhat more time than you expect!) and don't take the time to try (and usually fail) to be overly smart.
- hinkley 3y ago
  Reversible decisions are a simple enough concept to grasp, but a difficult one to really comprehend. Some people see effective people making 'bad' decisions and miss the bit where there were eight bad ways to accomplish something and they rejected 6 as being more work overall. Then they take their misreading of the situation as justification for YOLOing decisions to avoid analysis paralysis.
quietbritishjim 3y ago
> Because the previous design was not comprehensive enough to meet subsequent requirements. YAGNI. Hesitation to avoid unnecessary work, sure. But not to anticipate future requirements. The number of times I've had to fight a fancy design that left expansion points / abstractions for future features that were never needed (or not in the form the designers expected) enormously outnumber the times any such thing was useful. Just make the code do its current job in the simplest way possible. That's the easiest design to expand later.
- twh270 3y ago
  There's "simple" and there's "naively simple". I agree 100% with YAGNI, but you can also wedge yourself into a corner with a design that allows no room for growth unless you scrap it and start from scratch.
hirvi74 3y ago
> Why redo it? Is a reason like, "being built like shit by the cheapest contractors that won the bid" ever a good reason? My work is huge on what I call, "fire, forget, then rewrite." Basically, we have tons of legacy apps that have lifespans of like 10 - 20 years, many of which never receive a single update. So, they eventually get old and unsupported enough that it's honestly just easier/quicker to rewrite them. And in case you were wondering, yes, I work in Gov..

leetrout 3y ago

Hindsight / survivorship bias affects this viewpoint. You will never get it "right" the first time as much as you can avoid doing it "very wrong". The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains. Then you can refactor easier which should be the real goal. Prune and tend to the garden.

AnimalMuppet 3y ago
Yeah. It's easier to not do something stupid than it is to do something smart. Take the time to avoid doing stupid things (which takes somewhat more time than you expect!) and don't take the time to try (and usually fail) to be overly smart.
hinkley 3y ago
Reversible decisions are a simple enough concept to grasp, but a difficult one to really comprehend. Some people see effective people making 'bad' decisions and miss the bit where there were eight bad ways to accomplish something and they rejected 6 as being more work overall. Then they take their misreading of the situation as justification for YOLOing decisions to avoid analysis paralysis.

quietbritishjim 3y ago

> Because the previous design was not comprehensive enough to meet subsequent requirements. YAGNI. Hesitation to avoid unnecessary work, sure. But not to anticipate future requirements. The number of times I've had to fight a fancy design that left expansion points / abstractions for future features that were never needed (or not in the form the designers expected) enormously outnumber the times any such thing was useful. Just make the code do its current job in the simplest way possible. That's the easiest design to expand later.

twh270 3y ago
There's "simple" and there's "naively simple". I agree 100% with YAGNI, but you can also wedge yourself into a corner with a design that allows no room for growth unless you scrap it and start from scratch.

hirvi74 3y ago

> Why redo it? Is a reason like, "being built like shit by the cheapest contractors that won the bid" ever a good reason? My work is huge on what I call, "fire, forget, then rewrite." Basically, we have tons of legacy apps that have lifespans of like 10 - 20 years, many of which never receive a single update. So, they eventually get old and unsupported enough that it's honestly just easier/quicker to rewrite them. And in case you were wondering, yes, I work in Gov..