Developers should focus on writing satisfying software—software that meets the needs of users—rather than pursuing ideal software that aligns with personal or technical perfection. While striving for high standards has value, developers often fall into traps such as over-focusing on code quality, personal identification with their work, or enjoying the creative challenge of writing ideal software. To avoid these traps, developers need to stay disciplined and prioritize user satisfaction and feedback over their personal ideals and ambitions.
Is your code satisfying, or just beautiful?
Software developers have a habit of falling into traps. Traps make it difficult to write software and prevent or delay the needs of software users from being met. Among the most dangerous traps developers encounter is the pull, the siren's song, to chase ideals well beyond what's needed to satisfy users. While it is commendable that developers strive for ideals, they must always be on guard that their path is aligned with the software's purpose. These tendencies in software development can be considered as two poles of a spectrum:
In this view developers should seek to write satisfying software.
Software is written with specific objectives. Outside the realm of personal projects, these are rarely objectives of the developer themselves. Taking business as an example: satisfying users furthers business objectives; furthering business objectives makes money; developers are paid by the business. The incentive alignment should compel developers to write satisfying software. But, while always desired, this is not consistently achieved. Three forces conspire to divert these incentives and prevent developers from writing satisfying software:
The first force diverting developers from satisfying software is the insulation of developers from users. Given that developer-developer communication is more common than developer-user communication, they are more likely to heed the concerns of their peers than user needs. Since they are immersed in the development process rather than its end use, developers are more apt to say things like, "this code is bad and that code is good," than "this code satisfies the user and that code does not." A concern with software quality is good in moderation, it is part of a developers job. The trouble is the overamplification of that signal beyond reason.
This force often takes hold during bug fixing. Bugs are probabilistically experienced by users: for every bug in a ticketing system there is a % chance a user sees it. It's easy for developers to forget these probabilities when they look at code, know it is defective, but have no evidence the defect was ever observed by a user. The knowledge of the defect heightens the salience and ensnares the developer in its grasp. If they know something is broken, and they know it can be fixed, the urge is hard to resist. Developers can spend days or weeks fixing issues of this nature, concerns of the user be damned!
The second force diverting developers from satisfying software is a personal identification with their work. Developers are defined by the software they write. This obstacle is common in all creative work. For example, The Who's hit song "Pinball Wizard" was met by the band's immediate disgust. The curse of creative work is that its most popular outputs come to define the author. So in programming, just as in music, a feeling of insufficiency can take hold in delivering satisfaction which feels underwhelming by the author's judgement.
This force is most likely to take hold when developers are rewriting software. There is an urge to do something greater when doing it again. No one wants a new challenge to be more poorly completed than a similar one they've met in the past. So second-system effect—the tendency to over-engineer rewrites—takes hold, leading the developer down a course of idealism far removed from the software's true value.
The final force diverting developers from satisfying software is that writing satisfying software is boring and writing ideal software is fun. Fun work makes developers think it's supposed to stay that way. But outside the realm of personal projects, getting caught up in the fun can quickly lead to failure in delivering value. The late Nobel physicist Richard Feynman discusses a relevant experience in his book "Surely You're Joking, Mr. Feynman!": Adventures of a Curious Character:
Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. [...] The trouble with computers is you play with them. [...] You have these switches—if it's an even number you do this, if it's an odd number you do that—and pretty soon you can do more and more elaborate things [...].
After a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly—while he was sitting in a room figuring out how to make one tabulator automatically print arc-tangent X [...].
Absolutely useless. We had tables of arc-tangents. But if you've ever worked with computers you understand the disease—the delight in being able to see how much you can do.
The forces of ideal software are persistent, so developers must remain vigilant. But that isn't a call to throw quality out the window! Instead, the focus should be building something satisfying while incorporating ideals within the constraints. The best way to achieve this is through external feedback. For example, starting with a minimal viable product and iterating towards ideals connects the development process to user feedback early. This helps avoids overinvesting in software cathedrals which never achieve objectives. Additionally, soliciting feedback from other developers offers external perspective. Developers whose personality and emotion are removed from a problem can provide a useful recommendations on areas of focus.
The bottom line is that we are bad at predicting the success of our own creations, whether they fulfill our ideals or not. Connecting our theories to others' reality is the only way to determine practicability. So we should seek to make that connection as soon as possible, through MVPs, feedback, or otherwise. This ensures a grounded evolution of the software because, at the end of the day, the true measure of success isn't what the code looks like, but the value it delivers.