20 ms·
Faster to write -> faster to market Slower to write (and get right) -> fewer bugs to deal with later Pick your poison
by michaelcampbell 8y ago
Faster to write -> faster to market
Slower to write (and get right) -> fewer bugs to deal with later
Pick your poison
- coldtea 8y agoThat's really a no brainer. Having your company survive (because you got something faster to market), and having bugs to deal with later, is a so-called "nice problem to have". The bug-less software of a dead company does nobody good.
- dTal 8y agoQuick 'n' dirty might be fine for a move-fast-and-break-things web startup, but the world is much larger than that. I sincerely hope the people writing the software in, let's say an airliner to choose a topical example, choose option 2. Dealing with bugs that have killed people is not a "nice problem to have". (It depresses me that I have to write a defense of good engineering on Hacker news. The value of doing things correctly should be a tacit core principle of any engineer, to be broken only under circumstances of exceptional duress.)
- coldtea 8y agoMost domains are not of the "killing people" type. In those places, they also have other kinds of compliance requirements for the code -- which makes sense: I wouldn't leave the airline software PMs to chose between the above two options.
- dTal 8y agoMost domains are also not the "finish the job by next Thursday or the company folds" type either. You're going to have to pay back that technical debt someday, with interest - why not save time and do it right the first time? (Typical SV answer: you're only thinking of the short term because you're trying to get investment and you plan to exit stage left with a fat packet long before the technical debt rears its ugly head, leaving somebody else to clean up the mess. But this is not how most engineering is done in the real world.)
- coldtea 8y ago>Most domains are also not the "finish the job by next Thursday or the company folds" type either. Even in those that aren't, the managerial "finish the job by next Thursday or you're fired" is equally good motivator to not "save time and do it right the first time".
- pjmlp 8y agoApparently not paying for lack of quality and compensatory clauses seems to be a thing only in consulting.
- coldtea 8y agoYou'd be surprised. There are tons of stories of incompetent self-important consultants, coming in with big ideas, and getting paid mucho dinero per day for what amounts to nothing (if not actively bad advice). I've work with some. And don't get me started on the "specialist" consultants, whose job is to push some monstrosity, like IBM's stack, or SAP, or whatever, until it kinda fits the problem domain, and in the process sell even more crap from their vendor. Some fun stuff (haven't checked them all, but most stuff I've read from WTF across the years was hilarious, if not true to life): https://thedailywtf.com/articles/Consulting_The_Consultants https://thedailywtf.com/articles/Consulting_The_Consultants https://thedailywtf.com/articles/Invasion-of-the-Consultants https://thedailywtf.com/articles/Invasion-of-the-Consultants https://thedailywtf.com/articles/consultant-designed-success https://thedailywtf.com/articles/consultant-designed-success (And inversely, there are companies whose culture is all about good code and craftsmanship. But they usually don't get very far: if they don't fold, they're still niche shops. Perhaps Viaweb was one such).
- pjmlp 8y agoI am pretty aware of that and was already expecting such a reply from you. The point was that while for consultancy projects, customers do refuse to pay for what is considered a bad piece of work, for other kinds of software delivery, with exception of app stores, that never happens. It is very interesting experience to take part in a customer meeting, which isn't very pleased how things are going, regardless of the outcome. I also have my share of being part of such teams, similar to your examples, yet that doesn't mean one should stop pushing for quality as much quixotic endeavour as it might seem.
- pjmlp 8y agoBut they should, software should be liable just like any other kind of product.
- coldtea 8y agoMost products are simple components put together and made to do a simple thing under controlled conditions. Software is infinitely malleable and can be used under all kinds of environments (e.g. hardware configurations, OS versions, etc). It's more like a novel than a microwave. When you buy a novel you don't get your money back when it doesn't perform well, or puts you to sleep in the 10th page.
- pjmlp 8y agoActually around here refund laws apply to all products, including badly written novels. It is just that a large majority of population isn't aware of their consumer rights, or just doesn't want to bother.
- boomlinde 8y ago> (It depresses me that I have to write a defense of good engineering on Hacker news. Does it surprise you, though, on Hacker news?