Yesterday's article about code quality sparked some marvelous questions. Thread.
"Your list about what does matter instead of quality ... that's just code quality"
Yes it's _related_ to quality. A set of criteria that goes beyond code quality as engineers debate it. Instead of thinking about quality in isolation, think about what you're optimizing for.
"Code quality doesn't matter until it does"
My point is that code quality doesn't matter until it does and you can't know which code's quality matters until you find out empirically. There is just no way to predict it.
You develop spidey senses with experience and even the most experienced engineer will be wrong about which code is crucial 30% of the time.
Plus code that ships has a tendency to stay shipped and get improved over time. Code that doesn't ship doesn't get improved.
This is why talented engineers are so important. They can take shitty crappy code and still make it work.
"How do you convince management to care about code?"
I find management tends to understand this better if you're able to explain it to them in business terms.
"We hate working with this crap" is never a good argument and unfortunately often the only argument engineers can muster.
“This is how much money you are losing from poor retention, here’s how bugs X Y Z cause that churn, A B C is what we need to do to fix them, this will create $xxx/year more revenue than $yyy it costs in salaries to fix”
If $xxx < $yyy you will never fix those bugs or improve the architecture. Not worth it.
This is why you should work for profitable companies. If you’re not unit-economics profitable, then all talk about stability and reliability is pointless.
Which brings us to an important point: Code quality is a balance. A trade-off. Where the optimum lies depends on your company/product stage, what you're building, and other considerations.
Marketing experiment? Nobody cares.
Medical device? Super stringent.