getting to quality

 Posted on a small private Slack I enjoy (sometimes I think small Slack workspaces are like the future of social media) was this Forbes piece on how important code quality is, and how organizations absolutely Mug Peter to Pay Paul if they rush things early.

My further thoughts were this:

I think there are 2 ends of a spectrum to "what is code quality" and how to improve it:

1. the first is leans reductionist, like doubling down on confirming that each fine grained component lives up to its contract.

2. the second is more holistic; confirming the higher level pattern is appropriate to the problem space it is trying to deal with, with good inspectable flow and and not too many work arounds.

I think as code bases age and show evidence of needing updating, you tend to big pushes of the the former end. And so you get mandates to increase unit test coverage, and lines like "metrics-wise, we expect as line of code coverage increases faults in production will go down" which is.. quite a bit optimistic. (I am strongly in favor of higher level testing - the closer the context your tests are running in to what your production environment is, the more confidence you can have that whatever refactorings you have made preserve the key business values...)

But when trying to achieve improvements in the latter, holistic category... I think of the counter argument that starting a rewrite from scratch, armed with the experience of having done it once, often doesn't pay dividends because it's weirdly difficult to capture all the small improvements you made for edge cases. And so the obvious cost of doing everything over is still at risk for repeating many of the same mistakes and making its own cruftiness. (I imagine this is highly dependent on the circumstances and problem space.)

So there's no easy solution - if so you probably would have done it already! But I maintain my beliefs that everything good and bad about computer systems is an emergent property of interconnected parts, and as important as it is to be detail oriented, you need to think of forests more than you think of trees.