We all say that something is better than nothing, but code that does something has a special way of being worse than code that does nothing. Once something is happening, it can be shipped to production. This can initiate a feedback cycle that will stack changes on top of shaky foundations. These changes not only become increasingly harder to implement but also evolve out of flawed presuppositions.
Instead, we could have dug deeper. If we want a building with floors going up into the sky, we understand that first we must dig a hole. But software also has its own way of working that doesn't conform to physical limitations. Code can kind of work, but, if we don't let that fool us, we can also kind of let it into production but not really. We can see this in agile, beta software, early access, quality assurance, code rewrites... It's the iterative process of learning what we want to do from actually doing it.
Not to mention that code that works scores only a 10 out of 20, with shortcomings like:
Instead, we could have dug deeper. If we want a building with floors going up into the sky, we understand that first we must dig a hole. But software also has its own way of working that doesn't conform to physical limitations. Code can kind of work, but, if we don't let that fool us, we can also kind of let it into production but not really. We can see this in agile, beta software, early access, quality assurance, code rewrites... It's the iterative process of learning what we want to do from actually doing it.
Not to mention that code that works scores only a 10 out of 20, with shortcomings like:
- Can it work in a slightly different context or does it break as soon as any requirement shifts?
- Can it be extended to cover any last-minute requests or would that take too long?
- Can changes be made confidently without breaking existing expectations or does it have zero tests/types?
- Can it be maintained beyond its immediate development or is it only barely understood by the person who just coded it?
- Can it be deleted when it’s no longer needed or can its purpose become unclear soaking up time to maintain it?
- Can this code become faster to adapt, expand and dispose or just slower and slower?
No one is going to say to just do a bad job at it but, from the outside looking in, there’s s a natural resistance towards moving anywhere from code that kind of works. Don’t touch it. Let’s just hold it in place and see if it generates value. This can be a manageable risk if we’re aware of the shortcomings I’ve mentioned. But we also can’t get away from how the code reflects back unto the organization that creates it.
If we want good craftsmanship to be there when we need it, we can only recognize it if we cultivate it. Even when it’s hard to move beyond the 10/20 code, pushing for excellence at the very least allows us to look beyond the tar pit. We can’t predict the future, but let’s not get caught by surprise while rolling between single digits and that tempting 10/20. Instead let's get blindsided while grinding towards that 20/20.
In practice, these are some ways of reaching for a default score above 10:
- more or less mandatory code reviews
- version control as part of your workflow
- some meaningful test coverage
- good use of a statically typed language
As the pressure to get something to production mounts, some of these might start to get discarded or compromised, like code reviews or test coverage (not to mention documentation). Other more implicit decisions that were baked into a project, like having static types, can be harder to ignore even temporarily, but almost any of them can be sacrificed.
Still, all of these are actual commitments to quality and not just slides of a presentation. As part of company culture, these are all ways to think and communicate with our code, making it not only a part of our progress but also of our potential.