Nobody asked you to code like Kubrick

Let’s talk about artistry, craftsmanship and software quality. Writing code has been compared to an art as well as a craft. I love discussing the difference between the two and their relationship to quality. Software quality is a multi-faceted beast (functional correctness, usability, maintainability and all the other ilities). It’s impossible to judge the quality of a program by only looking at its source code, but it’s easy to recognise a clear lack of quality from any illegible tangle of spaghetti. Tools for quality metrics can point to such potential trouble but won’t guarantee that you’re building the right thing.

Anyway, if you take pride in your work, you don’t need tools to keep you on the straight and narrow. A true craftswoman always does the best she can. There is no such thing as too much quality, is there? Perhaps talk to the person who’s putting up the money. Quality saves money later, but it will cost you right now. From a business perspective the product needs to make money long enough to justify that expense. From an artistic perspective none of that matters. The true artist pursues quality for its own sake. Allow me a little segue into film and music.

Director/producer/screenwriter Stanley Kubrick (1928-99) was among the greatest cinematic auteurs of all time. He started in photography and rose to stellar fame with 2001, creating the illusion of weightlessness decades before CGI with impossible contraptions, at a time (1968) when popular sci-fi meant William Shatner in a bare-knuckle fight with an ‘alien’ in a Styrofoam suit. To shoot interior scenes by candlelight he acquired special lenses for Barry Lyndon. He revolutionised the Steady-cam to chilling effect in The Shining with mad axe murderer Jack Nicholson. He was technically as well as artistically innovative and never explored the same genre twice.

Kubrick’s reputation to seek perfection was also infamous among cast and crew. He produced his own films because no executive would have let him get away with the insane number of rewrites and retakes. Every frame had to be immaculate to make the cut. He sought a level of visual sophistication that went far beyond what you and I would even notice on the screen. He was an uncompromising artist. If pressed for resources he might have produced a masterpiece to us lesser mortals in half the time with half the budget, but it wouldn’t have been on his terms. In Agile terms, his user stories changed all the time, and the acceptance criteria were beyond reasonable. There are and have been many programmers with that level of dedication to perfection. Donald Knuth’s work in TeX springs to mind. 

Historically, the distinction between craftsman and artist has been blurry. You can argue that the craftsperson works from a recipe and the artist from inspired creativity. However, the operative word is skill. Salvador Dali painted from his twisted imagination, but you can tell it took him years of training. Handcrafted musical instruments are a great example where art meets skill. Making a high-end violin takes months of work and years of study. The craftsperson works from an established method, but no single piece of wood can be molded exactly alike. You won’t learn it from a youtube video. Put me in Heston Blumenthal’s molecular kitchen with a book of his recipes and I will still be helpless. In Agile terms there is however a clear difference with the autonomous artist. These user stories and acceptance criteria are at least very stable. Another difference between the prototypical artist and the craftsperson is that the latter needs to be more business-oriented. Whatever quality standard they have, if a price has been agreed then their time and resources must be limited.

The film 2001 and a €150,000 Bösendorfer grand piano have something else in common which doesn’t quite work in software: they are built first time right and built to last. With care and maintenance, a violin can be played for centuries without a single firmware upgrade. Let that sink in for a while. Built to last is a desirable feature for something you buy for the rest of your life. It’s tempting to apply it to software development, but that’s just not how the world works. In sub-disciplines like language and API design it is understandable to at least believe in first time right. It’s annoying and expensive to get second thoughts about your design a few years down the line, but that’s unavoidable. If software doesn’t change itself, the world around it will. The use case for building a piano has been stable for a few centuries. Compare that to the average JavaScript package manager.

Software lives in an inherently changeable ecosystem. You can argue that high quality demands are unwise if a product is not built for decades. The road towards perfection gets steep quickly. Turning a B plus into an A plus is hard, so let’s settle for a B. It’s bad business sense if you expect the code will eventually be discarded or refactored beyond recognition. Others will argue that you can’t predict when eventually will be. The legacy of Fortran and Cobol in our financial institutions wasn’t intended to last for decades, but it’s still there.

There are software gems, lovingly crafted by people who approach it as an art. But the business of delivering commercial software written to make money has a different purpose and you need to approach it with a different mindset to avoid frustration. Next time you are in an intake with a prospective client or employer, just ask how the company approaches quality and try to get a sense of the longevity of their code base. It can disabuse you of some false illusions. One thing’s for certain: you can only afford to code like Kubrick if you do it on your own or if you have the money to pay a talented team that will consent to be micromanaged for your grand vision.