[jruz]

You’re mixing product decisions with code decisions.

Product should make sure to create an MVP aka the fastest solution for A-B.

Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.

[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.

[mejutoco]

I see code as engineering, where there is no "right". There is "right" for the features, or right for the safety, or right for the budget, in a balance of compromises. Sometimes "right" is crappy code, and sometimes it is formally verified code.

[sktrdie]

Too bad "the right way" also differs between engineering experts.