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. I think business stakeholders are partly to blame for this (for reasons I will get to in a future blog post). However, 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.
No comments:
Post a Comment