7 ms·

too much confidence that we were building the right thing SW is weird in that way, we can basically build houses that nobody wants to live in. Thing is you pr

by kirse 4y ago

too much confidence that we were building the right thing SW is weird in that way, we can basically build houses that nobody wants to live in. Thing is you probably were building the right thing, structurally speaking. My rule over time has become "structure follows complexity" i.e. Anticipate complexity where possible but don't apply the engineering structure until the complexity really exists. If you built an MVP house, don't add the second bathroom until you've got customers complaining about deadlocks on the first. It's tough because that basically runs counter to the Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. The bonus of having two decades+ in building SW though is you start to see the patterns and realize that the same fundamental needs drive everything, so the intersection of building something great with customer needs becomes less of a mystery and more of a "how fast can we juice this thing". At that point I think scalability prep is like compound interest.

hinkley 4y ago
There’s a ninety ten rule with structure that can be hard to communicate in code reviews. There’s a subtle difference between not adding unnecessary structure and writing code that is antagonistic to it being added later. Opening a PR where someone added a feature or fixed a bug exactly where I would have done so is one of the best feelings. Especially when they’re changing my code. Either they’re a very good coworker or I’ve laid the groundwork well. Either of these are good news. Very recently I’ve come to think of my architecture style as Jazz. Like the old trope about listening to the notes he isn’t playing. But also the improvisational nature and the flexibility to adapt to new information.
- doctor_eval 4y ago
  > 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.
- pcblues 4y ago
  Jazz is an excellent analogy. Been in software dev for 30 years. It's hard to explain to hirers that one can only play jazz well (i.e. know what matters in a software project as you go) after a long time, so trust me :) I tried to bottle it in this document: https://pcblues.com/assets/pdf/approaching_software_projects.pdf https://pcblues.com/assets/pdf/approaching_software_projects...
  - hinkley 4y ago
    I realized at some point I got put in charge of things to shut me up. Someone would ask me why and I would launch into a treatise on all of the confounding factors and cognitive science reasons and and and OMG shut up already. Clearly you care about this more than I do, why don’t you do it? Don’t put a hyperkinetic person in charge of something thinking that you’ll call their bluff.
bcrosby95 4y ago
I call it "keeping an escape hatch". The potential need to scale and add features will inform my design decisions, but they will not direct them.
- pfarrell 4y ago
  "keeping an escape hatch". I like that. A former colleague said something similar that also stuck with me. Good software architecture allows you to delay decisions.
- damethos 4y ago
  I use "always keep an out", which is taken from poker terminology, but I like yours as well.
alexvoda 4y ago
China proves that building cities worth of actual houses that nobody wants to live in is a thing.
- andirk 4y ago
  We talking Dandong, city at the border of China and North Korea? They built everything including a giant bridge, high-rise apartments, shopping centers, parks, and a ferris wheel. But there's no people and it's been ~10 years now. It is, however, still fully maintained. [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
  - minusf 4y ago
    wikipedia says 2M people live there: https://en.wikipedia.org/wiki/Dandong https://en.wikipedia.org/wiki/Dandong
    - andirk 4y ago
      Yup. Literally first sentence of my citation "Dandong New City, a district of Dandong which was built from scratch to be a China-North Korean trade hub, now stands mostly empty." [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
- unity1001 4y ago
  A large number of those cities are filled, and various of them are 'tier 2' cities now. That means 10 million people.
  - tayo42 4y ago
    Wikipedia has only 7 Chinese cities listed with a population over 10 million
  - onlypositive 4y ago
    A large number of them aren't and they're crumbling apart after only a couple of years being built. https://youtu.be/XopSDJq6w8E https://youtu.be/XopSDJq6w8E
Frost1x 4y ago
>It's tough because that basically runs counter to the Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. I'm not sure if Spirit of an Engineer is a book, essay, or some prior set of principles I'm unaware of but if it's not (and even if it is), I tend to disagree here. The spirit of of an engineer, in my opinion, is to solve problems and problems for people--that's what I and most engineers I've spoken with have been drawn to (ignoring those purely seeking a high paying profession here since were talking about "spirit"). When I was youthful I sought out technical complexity and grandiose solutions (I admittedly still admire it when it's done correctly). None the less, to me, most of it is wasteful and at the end of the day I want to build the most useful solution for people to make their lives easier. Some problems require high complexity and glass cathedrals in terms of technical solutions, most really don't, at least most of the problems I've been exposed to.
- btilly 4y ago
  Actual engineers generally do try to solve problems for people. But the engineers understanding of the people that they are solving it for is generally rather flawed. And therefore their solutions frequently are difficult for the intended users for reasons that the engineer can't see. And yes, engineers really do err on the side of designing for future problems and future users that often will never exist. This effect is worst on a rewrite of a system - look up the "second system effect". We tend to only truly get pragmatic tradeoffs the third and later times.
- jgoodhcg 4y ago
  Maybe “spirit of an engineer” could be better phrased as “visionary mindset”. Lots of engineers I’ve worked with imagine potential problems and treat them as requirements to solve even though the problem may never actually materialize.
  - andirk 4y ago
    Figuring out which problems to solve before they happen and ignoring the ones that probably won't happen is the cosmic dance of software development. The Serenity Prayer states "... accept the things I cannot change, courage to change the things I can, and wisdom to know the difference." Except change "cannot"/"can" to "don't need to at least not yet"/"need to now because it's about to be an issue!". Make a bare bones version and see if it sticks, and go from there. Both the Progressive Enhancement philosophy and the Lean Startup methodology demand the minimal before building further. Ex: Will anyone click this survey link? Who knows but you'll learn real quick if you offer them $50. If they still don't, then it probably ain't gonna get clicked ever. If they do, then you found at least _something_ viable.
deleted 4y ago
[deleted]
yieldcrv 4y ago
you really couldn't write software? I’d vote for SWE if we are taking up acronym namespace
- kmoser 4y ago
  Writing "SW" instead of "software" is just another example of premature optimization.
chii 4y ago
> Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. i think that's just delusions of grandeur. Not everybody would be (or should be) building the sistine chapel.
lozzo 4y ago
Yours is an incredibly good comment. The comparison software/architecture is something that I have encountered here and there over the years, but you brought it to a new level. "don't add a second bathroom until you ve got customers complaing about deadlocks on the first". Beautiful. Thanks

by kirse 4y ago

hinkley 4y ago

There’s a ninety ten rule with structure that can be hard to communicate in code reviews. There’s a subtle difference between not adding unnecessary structure and writing code that is antagonistic to it being added later. Opening a PR where someone added a feature or fixed a bug exactly where I would have done so is one of the best feelings. Especially when they’re changing my code. Either they’re a very good coworker or I’ve laid the groundwork well. Either of these are good news. Very recently I’ve come to think of my architecture style as Jazz. Like the old trope about listening to the notes he isn’t playing. But also the improvisational nature and the flexibility to adapt to new information.

doctor_eval 4y ago
> 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.
pcblues 4y ago
Jazz is an excellent analogy. Been in software dev for 30 years. It's hard to explain to hirers that one can only play jazz well (i.e. know what matters in a software project as you go) after a long time, so trust me :) I tried to bottle it in this document: https://pcblues.com/assets/pdf/approaching_software_projects.pdf https://pcblues.com/assets/pdf/approaching_software_projects...
- hinkley 4y ago
  I realized at some point I got put in charge of things to shut me up. Someone would ask me why and I would launch into a treatise on all of the confounding factors and cognitive science reasons and and and OMG shut up already. Clearly you care about this more than I do, why don’t you do it? Don’t put a hyperkinetic person in charge of something thinking that you’ll call their bluff.

bcrosby95 4y ago

I call it "keeping an escape hatch". The potential need to scale and add features will inform my design decisions, but they will not direct them.

pfarrell 4y ago
"keeping an escape hatch". I like that. A former colleague said something similar that also stuck with me. Good software architecture allows you to delay decisions.
damethos 4y ago
I use "always keep an out", which is taken from poker terminology, but I like yours as well.

alexvoda 4y ago

China proves that building cities worth of actual houses that nobody wants to live in is a thing.

andirk 4y ago
We talking Dandong, city at the border of China and North Korea? They built everything including a giant bridge, high-rise apartments, shopping centers, parks, and a ferris wheel. But there's no people and it's been ~10 years now. It is, however, still fully maintained. [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
- minusf 4y ago
  wikipedia says 2M people live there: https://en.wikipedia.org/wiki/Dandong https://en.wikipedia.org/wiki/Dandong
  - andirk 4y ago
    Yup. Literally first sentence of my citation "Dandong New City, a district of Dandong which was built from scratch to be a China-North Korean trade hub, now stands mostly empty." [0] [0] https://www.globaltimes.cn/content/974210.shtml https://www.globaltimes.cn/content/974210.shtml
unity1001 4y ago
A large number of those cities are filled, and various of them are 'tier 2' cities now. That means 10 million people.
- tayo42 4y ago
  Wikipedia has only 7 Chinese cities listed with a population over 10 million
- onlypositive 4y ago
  A large number of them aren't and they're crumbling apart after only a couple of years being built. https://youtu.be/XopSDJq6w8E https://youtu.be/XopSDJq6w8E

Frost1x 4y ago

>It's tough because that basically runs counter to the Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. I'm not sure if Spirit of an Engineer is a book, essay, or some prior set of principles I'm unaware of but if it's not (and even if it is), I tend to disagree here. The spirit of of an engineer, in my opinion, is to solve problems and problems for people--that's what I and most engineers I've spoken with have been drawn to (ignoring those purely seeking a high paying profession here since were talking about "spirit"). When I was youthful I sought out technical complexity and grandiose solutions (I admittedly still admire it when it's done correctly). None the less, to me, most of it is wasteful and at the end of the day I want to build the most useful solution for people to make their lives easier. Some problems require high complexity and glass cathedrals in terms of technical solutions, most really don't, at least most of the problems I've been exposed to.

btilly 4y ago
Actual engineers generally do try to solve problems for people. But the engineers understanding of the people that they are solving it for is generally rather flawed. And therefore their solutions frequently are difficult for the intended users for reasons that the engineer can't see. And yes, engineers really do err on the side of designing for future problems and future users that often will never exist. This effect is worst on a rewrite of a system - look up the "second system effect". We tend to only truly get pragmatic tradeoffs the third and later times.
jgoodhcg 4y ago
Maybe “spirit of an engineer” could be better phrased as “visionary mindset”. Lots of engineers I’ve worked with imagine potential problems and treat them as requirements to solve even though the problem may never actually materialize.
- andirk 4y ago
  Figuring out which problems to solve before they happen and ignoring the ones that probably won't happen is the cosmic dance of software development. The Serenity Prayer states "... accept the things I cannot change, courage to change the things I can, and wisdom to know the difference." Except change "cannot"/"can" to "don't need to at least not yet"/"need to now because it's about to be an issue!". Make a bare bones version and see if it sticks, and go from there. Both the Progressive Enhancement philosophy and the Lean Startup methodology demand the minimal before building further. Ex: Will anyone click this survey link? Who knows but you'll learn real quick if you offer them $50. If they still don't, then it probably ain't gonna get clicked ever. If they do, then you found at least _something_ viable.

deleted 4y ago

[deleted]

yieldcrv 4y ago

you really couldn't write software? I’d vote for SWE if we are taking up acronym namespace

kmoser 4y ago
Writing "SW" instead of "software" is just another example of premature optimization.

chii 4y ago

> Spirit of an Engineer, which is just to imagine the grandest well-thought-out + organized thing and march toward creating it. i think that's just delusions of grandeur. Not everybody would be (or should be) building the sistine chapel.

lozzo 4y ago

Yours is an incredibly good comment. The comparison software/architecture is something that I have encountered here and there over the years, but you brought it to a new level. "don't add a second bathroom until you ve got customers complaing about deadlocks on the first". Beautiful. Thanks