3 ms·

> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long

> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it. "build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).

dceddia 4y ago
My mind jumps to things like.. - Don’t rewrite the architecture with microservices when the monolith is working fine - Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so. - Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple. This is just a guess though – if you have some examples from your own experience it would be great to hear about some!
- IshKebab 4y ago
  Can't disagree with any of those really. I guess it's really hard to draw out general conclusions about these sort of things when the specifics really make a difference. You can pretty much say "spend your time wisely" which is not very actionable. For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc. I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.
  - bluefirebrand 4y ago
    Premature optimization is much more useful as a deterrent for stuff like building complex data structures and processes to speed up looping through like 100 items. "But it might be a million items later!" Yeah, or the company might pivot before we ever go live with this feature. Just slap a for-loop in there and get on with your day.

dceddia 4y ago

My mind jumps to things like.. - Don’t rewrite the architecture with microservices when the monolith is working fine - Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so. - Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple. This is just a guess though – if you have some examples from your own experience it would be great to hear about some!

IshKebab 4y ago
Can't disagree with any of those really. I guess it's really hard to draw out general conclusions about these sort of things when the specifics really make a difference. You can pretty much say "spend your time wisely" which is not very actionable. For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc. I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.
- bluefirebrand 4y ago
  Premature optimization is much more useful as a deterrent for stuff like building complex data structures and processes to speed up looping through like 100 items. "But it might be a million items later!" Yeah, or the company might pivot before we ever go live with this feature. Just slap a for-loop in there and get on with your day.