Are you a perfectionist? Do you continue to work at a problem until you get it absolutely right, with the most efficient code, executing in the quickest time, and taking the least resources? Chances are that if you are programmer or a developer, you either are a perfectionist or lean very strongly in that direction. It is not unusually because the nature of programming lends itself to perfection. After all, either the application you write is right or it is wrong. There usually is no ‘close-enough’ answer. But as a programmer or developer, do you take getting the ‘perfect’ answer to extremes?
Don’t feel that I’m criticizing. I was a programmer/developer for many years and know very well the lure of perfection in every project I’ve ever done. However, sometimes just getting the right answer isn’t what gets you up in the morning for another day of pounding the keyboard. I know what it is like to spend hours trying to find a faster way for the code to run. In some ways it is as addictive as playing a video game and trying to top that high score even though that high score is your own. Perhaps this is in part the reason why programmers can finish 80% of a development project in 20% of the time. While I grant you that sometimes that last 20% of the application involves some very tricky (read that as complex) programming, it is often just to add those last features (bells and whistles) to make the user interface memorable. But from a project standpoint, sometimes 80% is good enough and that extra 20% is not really as important as other work you could be doing.
It is not the latest programming language or newest development platform or the coolest database that creates the greatest challenge for programmers. Rather it is the understanding of the cost/benefit of making those final additions to a program that is one of the hardest concepts for programmers to learn. Part of the reason for this perhaps is that programmers don’t really have to deal with running the program on a regular basis after they finish coding it. They don’t have an inherent feel for the cost of making those final enhancements that take a month of development time verses the benefit those enhancements have when saving only 5 minutes a month for each time the program is run by the end-user. This is where a project manager or project lead needs to step in and weight the costs against the benefits and if necessary refocus the developer into other more productive tasks.
Part of this decision also involves clearly understanding the needs vs. the wants of a project. Needs are non-negotiable features and options in the program that must work and work correctly for the project to be considered successful. In fact, a project cannot be closed out unless it satisfies all the needs unless a decision is made to cancel the project completely. The fulfillment of the project needs may make the project run over budget or over time or both. In this case, wants are sacrificed in order to meet all of the needs with a minimal of additional cost or time. On the other hand, wants are just that. Things that the project owner would like to have but can live without but which only get addressed after all the needs have been satisfied. Obviously the project budget or timeline determines whether any wants get addressed. Unfortunately, decisions to forgo wants often leave developers with a sense of unfinished tasks.
If this happens often, developers may feel that they never get to finish a job and their sense of job satisfaction becomes seriously undermined. This is where the job of the project manager or project lead is to work with the programmers to help them celebrate the success of achieving all of a project’s needs even if none of the wants are addressed. Perfection is sometimes just meeting the needs of the project owner. Another way to look at this is if the project owner wanted a pocket knife, it may be better to supply them with a really good quality, sharp pocket knife guaranteed to stay sharp for the life of the product than to give then a Swiss Army knife with blades that are hard to pull out and which may not even be sharp enough to cut a sheet of Jello.
Speed of performance is another perfection trap. Several years ago there was a report that took nearly three hours to run. There were many reasons for this long execution time, but the bottom line is that by changing the way the report would be generated, it eventually tool only five minutes to run the report. Since this report was run fairly often, the cost of developing the new solution which took about 2 days was clearly worth the 2.9 hours saved each time someone ran the report. On the other hand, I thought I could get the time down to 2-3 minutes, but it would take another 2 days to do that. At a savings of only 2 additional minutes, it would take over two years to justify the expense of gaining that last performance boost. As a perfectionist programmer, I really wanted to do it, but as a more realistic project lead, I knew there were better uses for my time.
Do you have any perfectionist stories that you would like to share? If you do, include them in the comments.
A final reminder, this weekend is SQL Saturday in Jacksonville, FL. For details on the session schedule and directions to the event, go to: http://www.sqlsaturday.com/130/eventhome.aspx.