The James Webb Space Telescope is finally up and running, bringing back images of galaxies at mind-boggling distances from Earth. Hubble’s successor was three decades in the making and cost more than ten billion dollars. The code executed on hardware a million miles from Earth must have been written with superior attention to detail and quality. Well, I assume.
The cost to get the reliability you need for those top echelons of mission-critical software is highly non-linear. Squeezing out a hundredth percentage point, to go from 99.99% to 99.999% uptime, is expensive. It must be worth the effort. So, we adjust quality needs based on risk. How much will we suffer if the software reveals crucial bugs after deployment? How likely is this and how do we mitigate those odds? How fast can we track down and repair mistakes? For the Webb telescope, the answer is obvious: the reputational damage alone would be devastating. If serious bugs ruin a project because they can’t be quickly rectified, then a mega investment in first-time-right is justified.
My guess is that the folks on the Webb team count a fair number of clean code purists. In that community, a principled love of quality counts as the true hallmark of professionalism, and its members defend their dedication to the craft with a lot more zeal than your average lawyer or dentist. The latter already have steep and expensive entry requirements, whereas the programming game is readily accessible to amateurs. Sure, we have certifications, but everyone can call themselves a software developer without immediate fear of a malpractice suit.
Sometimes a B Minus Must Do
If you take each aspect of quality equally seriously, the scope for improvement is limitless. This goes beyond functional correctness and includes readability, adaptability, usability, portability, and a dozen other “-ilities.” You can basically keep polishing forever. But if you do so for a paycheck, you risk taking your craftsmanship too far. I have seen it among senior clean coders who work on less than business-critical software or glorified prototypes; software with a short shelf life that cannot demand top quality. We can’t justify the costs to get an A plus, so a B minus must do. If you find that unacceptable, perhaps you want to share part of the bill? Craftsmanship cannot only be focused on maximizing quality. Sometimes you must compromise to optimize. And note that I’m not Saying you should ever get away with bad software, just that the price for getting from good to excellent often makes poor business sense.
The cleanest coders still hate to make concessions like that. They care little about deadlines and risk burnout to deliver the work timely and adequately. This is not a blessing for the group. Perfectionists are rarely great team players or even tolerable company. Read Walter Isaacson’s brutally honest biography about Steve Jobs, with his amusing and completely impractical insistence that all Apple machines had to look beautiful on the inside as well.
Computing as an Art
If you have a level of commitment equal to Steve’s, you qualify as an artist. If quality is always more important to you than mundane concerns like what the customer wants and when they need it, you’re treating your trade as an art.
Artistry is as much about attitude as it is about the quality of your output. An attitude to be consistently good is what separates the amateur from the artist. I’m a decent classical singer, having had years of private lessons. What keeps me firmly in amateur territory however isn’t so much my limited vocal range, but that I don’t push my skills to the limit. I have good and bad days, but an artist cannot afford to let bad days affect their performance. The stage actor playing Macbeth puts his reputation on the line every night, whatever the venue or audience turnout. Only the amateur claims they need the inspiration to get going.
The artist’s loyalty lies with the craft and how she believes it should be practiced, whether the effort is spent on a throwaway game or on the Large Hadron Collider. In an employment relationship, they will only sign their name grudgingly under work that doesn’t meet their standards. But we didn’t hire you as an artist. Such an attitude leads to friction in a software team if others are more pragmatic.
Vaporware Never Solidifies
Even if you have a team of artists, or there’s an artist at the helm, it’s no less problematic. You may never ship anything. There are plenty of examples of such vaporware projects inspired by grandiose visions of digital innovation that never solidified. Here are two of my all-time favorites.
There was the sympathetic but ultimately doomed Chandler project, a labor of love started by pioneer Mitch Kapor, who made his millions with Lotus 1-2-3. The dream of Chandler becoming the all-in-one open-source information manager that would kill Outlook was commendable, but the job proved undoable. Their scope was too ambitious and the user experience too different from what people already knew, and several times they bet on the wrong horse in terms of architectural choices. The industry had gone another way. The whole sad story is beautifully captured in Scott Rosenberg’s 2007 book, “Dreaming in Code.”
But the mother of all pipe-dream projects has to be Ted Nelson’s Project Xanadu, which Wired described as the longest-running vaporware story in the history of the computer industry. Nelson, a philosopher and techno-anarchist, got some fame in hacker circles with his self-published opus “Computer Lib” (1974), a rambling rant that makes William Burroughs’ “Naked Lunch” seem a coherent narrative. The first plans for his superior hypertext system date back to 1960, long before implementation was even feasible on the hardware of the day. Even so, it took until 2014 for a working deliverable. While his ideas predated Tim Berners-Lee’s HTML by three decades, working software was hopelessly late to the party. Do read Gary Wolf’s long article from 1995 about the key players in this bewildering tale. To call these men eccentric is putting it mildly. Why hasn’t this been made into a TV series yet?
A habit of non-productive perfectionism in software, like many other psychological traits, exists on a spectrum. I have been describing an archetype at the far end. Too much perfectionism usually isn’t the problem in a team. Pragmatists, who are committed to delivering, are more common, but they need to know when to control their willingness to please the customer. They must remind themselves that while we do not reach for the stars, anything less than a B minus isn’t acceptable either. And if you’re a clean coder you must learn that best practices are not articles of faith and quality should be negotiable. When it’s clean enough, you stop. To borrow from Jerry Seinfeld: You can’t over-die, you can’t over-dry.