> 1. They never get enough developers. 2. They usually get deprioritized in lieu of other projects.
As a dev currently building out several fairly-complex in-house tools for a small startup, I can relate to this first-hand.
It’s enormously frustrating as a perfectionist with a slightly neurotic obsession with (in a balanced and healthy way, trust me ;D) and appreciation for best practices, I have had to (against better judgement) sacrifice many things such as extensive time spent on in-depth automated testing, abstraction of reusable code for polymorphism and shared packages, extremely in depth documentation, and many other aspects that would contribute to long term viability and efficacy. This is of course for the sake of a business-friendly timeline, and that I can appreciate.
There is a definite balance, and I have (and continue to) learn enormously from this business view on software. The “it just works” ethos can be scary further down the road. The economic upsides to this perspective for an MVP or POC type of development are absolutely massive, but I can’t help but think this could be supplemented further by dedicating more resources to focusing on best practices.
Whether that focus comes from an internal team with more dedicated resources or a third party, I’m still unsure as to how that decision should be made.
Either way, it has been very helpful in further developing my skills in communicating things like tech debt (what notions like automated testing actually mean in terms of value to a SaaS company) to the CEO and other colleagues who do not have software dev experience.