A $5 solution to a $5 problem

When I was in band instrument repair, I dedicated myself to becoming the best repair technician possible. I was constantly looking for ways to make my instruments respond more quickly, play with a fuller tone, etc. I got pretty good at it if I say so myself. However, I found that it's not possible to do that quality of work on every instrument and be able to make a profit. Most instruments just do not deserve to get that attention to detail. As a telling example, I would look at a student flute, which cost the store about $250, and decide that it needed $600 worth of work to get it in order. And that was typical for brand new flutes. Yes the manufacturing was shoddy, but I had lost any sense of context for quality in my work. I could only define "quality" as the best possible end product, which I now realize may or may not have been what my customer needed.

Luckily, I found a new balance in computer programming. Yes, it is satisfying providing that super-fast, bullet-proof, wonderfully designed software application to a business user. Thankfully I'm just as happy providing an adequate solution, knowing that in some cases the business stakeholder values low cost and short time-to-market more than they do software perfection. My goal is to meet the user's needs in the best way possible, not provide the best end-product possible.

I'm quite disappointed, however, to see a vast number of developers who are doing the software equivalent of putting $600 worth of work into a $250 flute. These developers are making the same mistake that I did as a band instrument repairman – losing sight of the customer's needs to satisfy one's own arbitrary set of standards. We as developers need to renew our focus on making sure there is a good reason for each and every line of code we write. If it does not add more value than it costs to write it, then doesn't belong in the project.