top | item 36517972

(no title)

jruz | 2 years ago

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.

discuss

order

mschuster91|2 years ago

> 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|2 years ago

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|2 years ago

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|2 years ago

> 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|2 years ago

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|2 years ago

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