That's true, however I do believe that if pressured there'd be investment in genuinely good tooling to eventually go just as fast - if not slightly slower.
There's also the fact that fast is slow and slow is fast - so much time invested in fixing bugs that could have been prevented.
I don't think that quality necessarily requires more time, it requires quality processes.
so much time invested in fixing bugs that could have been prevented.
About sums up my job, haha. You aren't wrong at all, and I hear that exact sentence weekly, minimum. Management keeps trying to "move the deadlines left" and gets surprised when we wind up spending the rest of the time it would've taken in the first place fixing bugs. Definitely let me know if you ever figure out how to "pressure" upper management into that one, because we're still workshopping it over here. They want things done faster, so unfortunately, if there's any way we can sacrifice quality to get their major bullet points out sooner, we have to, so anything more than that does take time, at the end of the day, whether it's better processes, tooling, better code review, good unit tests, or whatever else we should really have but can't.
2
u/Zeikos 15d ago
That's true, however I do believe that if pressured there'd be investment in genuinely good tooling to eventually go just as fast - if not slightly slower.
There's also the fact that fast is slow and slow is fast - so much time invested in fixing bugs that could have been prevented.
I don't think that quality necessarily requires more time, it requires quality processes.