Hacker News Reader

Comment by bryanrasmussen | Hacker News Reader

I distrust any engineer who writes quality is infinitely superior to quantity.

I think you might have the idea that "Quality" is some sort of nitpicking, ambiguous goal. At most places I've worked, it just means well thought out, tested, architected code that follows best practices.

Why? Obviously this doesn't apply to everything, but given that the marginal cost of another copy of an application is zero, it does seem to apply to software.

Because "good enough" usually works just fine. Also because navel-gazing doesn't get anything done -- projects stagnate and rot and often disintegrate entirely when they don't ship in a reasonably quick time-frame. If they do make it out, they're often clear bastardizations that aren't useful to anyone but somehow escaped the dungeon of development hell. To avoid this, ship early and ship often.

Just look around. The computing world is not designed by committee (although there's no shortage of pontificators and committees trying to pretend they're relevant). Someone makes a quick draft and throws it out there. People see potential, adopt, and then mutate/improve upon whatever building blocks help them attain their goals with the smallest amount of effort (NOT which building blocks best comprise their concept of an ideal project).

JavaScript is a great case study that demonstrates this very well.

This is true in general.

But I think there are some things that we should be 'thoughful' about. APIs, and platforms come to mind.

Typescript is amazing. It's evolved, and they've 'added on' - but if they had to do fundamental re-works ... it would not be good :).

Also ... security ... anything dealing with money ... the risk equation is different, and it just helps to be thoughtful.

For an enterprise problem that is not super-complex, and fairly straight forward, but which involves money or legal issues ... a slow and classical Eng approach might be optimal.

JavaScript is a great example. It was hastily thrown together, not well thought-through, and didn't wind up being a substantial competitive advantage for its corporate owner Netscape, which is now defunct.

But we are still suffering from the aftermath. I wonder how much better the web coding world would be if Brendan Eich had been able to spend 60 days on it instead of the 10 was given?

Yeah, I absolutely agree that we've felt the sting of JavaScript for far too long, but the fact that it's so hard to replace only further demonstrates the point. People are optimized to expend the smallest amount of energy necessary to reach a certain point. Unless a new client-side scripting language comes out and enables something that practically everyone, even non-programmers, wants and wasn't reasonably doable before, JavaScript is here to stay.

Meanwhile, committee-designed projects like Dart have floundered and ultimately failed in their ambitions to bring a better client-side scripting language to the web, despite the backing of the largest internet company on the planet.

JavaScript is a great example because if it wasn't completed there wasn't anything in particular that we know of that could have been sure to win.

I wonder how much worse it could have been. The only thing really competing with JavaScript in its early years was VbScript. If Netscape didn't make a solution, Microsoft probably would have. And that would most likely have been something like VbScript. Not infinitely worse, but quite a bit worse.

Okay... but you're contrasting quality with quick and dirty, not with "more is better" (ie. quantity).

More users is obviously good, as are more releases, but more commits? More repos? More LOC?

I read the post as stating that "Quality [of releases] is better than quantity", which is patently false IMO -- in fact, I would say that quantity of releases is pre-requisite for quality. Software grows up best when it's submitted for user feedback frequently and iterative changes are made based on that feedback. Waiting until something's perfect, or even "high-quality engineering", means it never gets done. A strong shipping bias is necessary to get software that works and works well.

Okay, that's a reasonable interpretation. However, mine was "quality [of code] is better than quantity" or "quality [of features] is better than quantity".

Like the way Lean defines "waste" (muda), the meaning of "quality" and "quantity" in the world of software are highly context specific (and should usually be tied to customer perception).

I actually just meant that assigning a value of infinity to something makes comparison between that and the non-infinite really tricky (I mean I might accept that quality is 10X superior to quantity [assuming the mythical 10X engineer], but infinitely superior?)

But your point is also good. My first big application was basically sunk because a coworker froze up on making some functionality because he couldn't figure out a way to do it perfectly - that is to say he knew no matter what that he would have to rewrite that functionality in 6 months to a year, as a consequence he spent nearly 2 months not doing anything trying to figure out how he wouldn't need to do that rewrite.

Anecdotal example that apparently stung you too deep. Sorry for that.

You should know there are some of us who are quite disciplined and self-reevaluate fairly often. If I was on the place of your engineer I'd spend 2 weeks at most and then just think it through the weekend -- why is this taking so long? Am I overthinking the possible future plans for this feature? (Very likely.) What are the main hurdles? (I'd write them down and analyze them one by one.) What makes me think a quickly put together code isn't good enough?

It seems you had a junior developer put in a situation too big for their non-technical abilities. Again, this is nasty and I am sorry that you have been bitten by that.

But please have in mind there are many other programmers out there who can do a much better job from the organizational (non-technical) side of things.

https://www.dreamsongs.com/WorseIsBetter.html

I could not find a reference to RPG's famous essay here, so I'm guessing it will be new to some folks.

Mind you, WiB can be taken as license to do worse, which is sometimes just worse. JS in ten days actually got worse in the next 20 as I had early adopters ask for sloppy == and so on, and I gave them what they wanted. My fault for caving, but also part of the gamble to start fast and grow quickly.

What people miss about the Web is the backward compatibility constraint, very real at almost any scale and reinforced by browser competition. As I RTed recently, "replace" is spelled "e x t e n d" on the Web. This is a lesson Dart and other well-heeled projects ignored, in spite of many (including inside Google) telling them so.

So WiB means get on first, worse enough that you are first, better enough over time that you don't get replaced. By that criterion, JS is a huge success. Haters even turn around thanks to the language evolving toward ever-better extended editions such as ES2015 and beyond. See http://node.green/.

Reply on news.ycombinator.com