Earlier quoted context omitted.
Depending on what you mean by "code" I disagree. 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. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes.…
> 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 tho…
- 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!