[mschuster91]

> Code should be done right no matter what, you’re being paid as an expert to do that

As I've written in a recent thread... that may be the case in the academic world, but certainly not in the business world, where time-to-market and profitability always trump code quality if not explicitly required / audited by client contracts.

[defrost]

Somewhere twixt the two is another domain; the hard equation engineering world.

Computations along novel curved beam configurations have to be correct, 400 m deep billion dollar / annum mine stope angles need to be both aggressive and safe, et al.

Often there's not as much competition as might be in other domains, and while profitability pays the bills the real onus is on the production of provably correct software (to the greatest degree practical).

[smugglerFlynn]

The problem sounds more like "how do I deliver quality code when 95% of companies out there do not see quality as an objective, oversell poorly made PoCs, do not give space and resources for design and engineering, and pushback on any refactoring?"

The answer is very simple: you don't.

[pyrale]

> where time-to-market and profitability always trump code quality

What actually happens is more like :

"deliver as fast a possible, no matter what"

...

"The poc was delivered in a week, why are new features so slow? And can you explain what this refactoring item adds to the bottom line?"

[mejutoco]

That seems like a failure of management.

[pyrale]

Well, if one's management consistently fails in a predictable way that one can adapt to, one should probably adapt to it regardless of whether they believe it's a failure.

[mejutoco]

That is one option, and it is fine. Adapting to people treating a PoC as a full product by making it a more full-featured product is basically stopping doing PoC.