3 ms·

What you seen to be ignoring is that the startups you worked for had the chance to fail due to bad code quality at all. And that was likely due to the fact they

What you seen to be ignoring is that the startups you worked for had the chance to fail due to bad code quality at all. And that was likely due to the fact they they shipped features without worrying about code quality so much. It's counter intuitive that high code quality is appropriate once a startup has found some kind of product market fit, but is wholly inappropriate until then. It's a very jarring thing to tech people but to people who really understand business it's very obvious or natural.

nicoburns 6y ago
Is the suggestion that high quality code is slower to write / iterate on? Because that hasn't been my experience.
- girvo 6y ago
  I think one can make the argument that it’s cheaper (in the short term), but I agree that it’s not inherently faster to develop. But experienced devs who can build high quality well modeled software fast aren’t cheap, haha
- spfzero 6y ago
  That depends on the developer, some need to slow down, go back and rewrite, etc. Others write naturally good code without much extra effort. Maybe partly experience?
- lumost 6y ago
  Back in the day a lot of OO startups burned precious time on taxonomy debates and UML diagrams. There are productive code quality discussions, and ones that don't ultimately matter.
- JamesBarney 6y ago
  I think there are some code quality trade offs you get for free. You should always make those, like don't write shitty variable names. But there are a lot code quality decisions where increasing quality costs more time. (at least in the short run) Code consistency - When you write one module one way and a another dev writes it another. Do you rewrite one of the modules for consistency? Doing the "Right" thing - When there is a better solution and a faster solution that is maybe less maintainable. Which solution do you pick? Corrections - You wrote some code while learning a new library/technology/api and find that you used it poorly. Do you go back and clean this up? Code Reviews - How nit picky are you? How good is good enough? If a dev writes out a large feature and you don't like the way he did it do you ask him to fix it? Database Mistakes - as you learn about and build out your app you realize you made the wrong choice with some database modeling, do you fix it or write unnecessarily complex SQL to fix paper over it? Analyze or fix CSS - A button looks weird, you're not sure why the css is causing it to render funny. Do you do a deep dive finding the root cause or do you just jam some inline css in there?
  - dSebastien 6y ago
    As you say, some tradeoffs are free, others aren't. One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits for code quality and overall FE architecture, but it also introduced additional layers, which required more code here and there for all details. Entities that we get back are stored separately, then put together through selectors when they're needed on a screen. And all that jazz does take time & energy. The net result is data consistency across components/screens (which is great), separation of concerns and clean code (cool), but at the code of slower development. Even though, as I'm writing this, I also think about the alternative. Not having it means having less structure, maybe more issues to fix everywhere due to the lack of consistency, etc. It's not a choice that I can weigh easily, even now. I knew the tech already, used it in production before, and it still wasn't easy after all. Details details ^^
    - burnthrow 6y ago
      First, great blog post. > The net result is data consistency across components/screens (which is great) You probably don't need to be told this, but... how badly was the data really going to drift during a session? If a user notices that part of the UI is stale, they just hit reload, not a big deal. This could be improved later.
      - dSebastien 6y ago
        Yep, good point. I do see it now. I absolutely didn't back when I started working on that. I had just delivered & supported an enterprise front-end framework (https://stark.nbb.be/ https://stark.nbb.be/) for which we HAD to help fix issues with state management. But of course, I just looked at it from the wrong point of view... The point of view of a technical guy, and not the one of a founder. I'm learning.. ;-)
hinkley 6y ago
Switching those cultures is a challenge. The sort of personality that got you your first ten sales doesn’t want to stop coding that way, and if someone doesn’t step in, then that precedent becomes your culture. They never grow up. One place dealt with Rube Goldberg code forever because most of the people who thought it needed to be fixed left. People conflate “if the code didn’t start that way then we wouldn’t have a product and thus we wouldn’t be having this conversation” with “there’s a good reason for the code to continue being that way”
dSebastien 6y ago
Well put. I do feel the counter intuitiveness at this point ;p But what you say sounds correct to me.

nicoburns 6y ago

Is the suggestion that high quality code is slower to write / iterate on? Because that hasn't been my experience.

girvo 6y ago
I think one can make the argument that it’s cheaper (in the short term), but I agree that it’s not inherently faster to develop. But experienced devs who can build high quality well modeled software fast aren’t cheap, haha
spfzero 6y ago
That depends on the developer, some need to slow down, go back and rewrite, etc. Others write naturally good code without much extra effort. Maybe partly experience?
lumost 6y ago
Back in the day a lot of OO startups burned precious time on taxonomy debates and UML diagrams. There are productive code quality discussions, and ones that don't ultimately matter.
JamesBarney 6y ago
I think there are some code quality trade offs you get for free. You should always make those, like don't write shitty variable names. But there are a lot code quality decisions where increasing quality costs more time. (at least in the short run) Code consistency - When you write one module one way and a another dev writes it another. Do you rewrite one of the modules for consistency? Doing the "Right" thing - When there is a better solution and a faster solution that is maybe less maintainable. Which solution do you pick? Corrections - You wrote some code while learning a new library/technology/api and find that you used it poorly. Do you go back and clean this up? Code Reviews - How nit picky are you? How good is good enough? If a dev writes out a large feature and you don't like the way he did it do you ask him to fix it? Database Mistakes - as you learn about and build out your app you realize you made the wrong choice with some database modeling, do you fix it or write unnecessarily complex SQL to fix paper over it? Analyze or fix CSS - A button looks weird, you're not sure why the css is causing it to render funny. Do you do a deep dive finding the root cause or do you just jam some inline css in there?
- dSebastien 6y ago
  As you say, some tradeoffs are free, others aren't. One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits for code quality and overall FE architecture, but it also introduced additional layers, which required more code here and there for all details. Entities that we get back are stored separately, then put together through selectors when they're needed on a screen. And all that jazz does take time & energy. The net result is data consistency across components/screens (which is great), separation of concerns and clean code (cool), but at the code of slower development. Even though, as I'm writing this, I also think about the alternative. Not having it means having less structure, maybe more issues to fix everywhere due to the lack of consistency, etc. It's not a choice that I can weigh easily, even now. I knew the tech already, used it in production before, and it still wasn't easy after all. Details details ^^
  - burnthrow 6y ago
    First, great blog post. > The net result is data consistency across components/screens (which is great) You probably don't need to be told this, but... how badly was the data really going to drift during a session? If a user notices that part of the UI is stale, they just hit reload, not a big deal. This could be improved later.
    - dSebastien 6y ago
      Yep, good point. I do see it now. I absolutely didn't back when I started working on that. I had just delivered & supported an enterprise front-end framework (https://stark.nbb.be/ https://stark.nbb.be/) for which we HAD to help fix issues with state management. But of course, I just looked at it from the wrong point of view... The point of view of a technical guy, and not the one of a founder. I'm learning.. ;-)

hinkley 6y ago

Switching those cultures is a challenge. The sort of personality that got you your first ten sales doesn’t want to stop coding that way, and if someone doesn’t step in, then that precedent becomes your culture. They never grow up. One place dealt with Rube Goldberg code forever because most of the people who thought it needed to be fixed left. People conflate “if the code didn’t start that way then we wouldn’t have a product and thus we wouldn’t be having this conversation” with “there’s a good reason for the code to continue being that way”

dSebastien 6y ago

Well put. I do feel the counter intuitiveness at this point ;p But what you say sounds correct to me.