5 ms·

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 pric

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.

taneq 7y ago
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.
dawidw 7y ago
> 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.
- ilovecaching 7y ago
  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.
celticmusic 7y ago
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.

taneq 7y ago

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.

dawidw 7y ago

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

ilovecaching 7y ago
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.

celticmusic 7y ago

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.