Hacker News Reader

Comment by ilovecaching | Hacker News Reader

I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free.

So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and software craftsmanship aren’t worth it, it’s that companies and the engineers who build them from startups don’t care and are focused on keeping their doors open. Long term health is a very secondary concern.

I’ve done my fair share of preaching that we should refactor and start focusing on quality during code reviews and it’s basically just shouted down with “don’t fix what isn’t broken” and YAGNI.

View on HN

While I share your nihilism about engineering quality in a startup environment, if you don't keep your doors open, the long term health of your codebase will fall to zero.

If you have an established, cashflow-positive company that's not hell-bent on scaling fast (or being forced to scale unnaturally by VC backers) then the balance swings back and it becomes worth investing in your codebase.

> Literally the only thing that matters is moving fast

> Code quality is really not important at all as long as the product works and is bug free

According to Robert C. Martin is not possible to move fast without good quality.

That's the thing though. Martin says that, but then you watch a company scale to billions of people ignoring all of his advice. So the question is - does Martin actually have quantitative proof that what he is saying is correct, or is he just selling wishful thinking? The field of software engineering as an academic discipline is the least understood of the computer science subfields because it's qualitative not quantitative field.

Of course scaling to billions of users only proves that it can be done without quality, not that they could have done it better with quality software.

I recently walked away from a client who had this attitude. I want to take pride in my work, when I cannot I suffer for it.

The way I look at it is the following:

There are times to take the shortcut (Business reason, for example), and there are times to do the technically sound thing (long term health, usually).

A healthy software team is doing both as it makes sense. That's quality software dev. It's when business takes over the software teams decisions and you always take the shortcut that quality falls off a cliff.

I've worked in those environments too much. I want to be able to take pride in the work I do.

Reply on news.ycombinator.com