Monday, June 07, 2004

What is Excellence in Software Development?

I recently attended an awards banquet, and after thinking about the events that transpired, I had to sit down and write this entry. One of the VP’s who was honoring the award recipients had a great concept buried in his speech that I am now paraphrasing – that we need to recognize everyday excellence, not just the people who are acting in “Firefighter mode.”

What are “Firefighters?” In any company this type of stuff happens more than we would like to admit. The situation may be a big demo. Six hours before the demo, your equipment arrives. What remains of the shipping crates looks like it was used as landing gear for the transport plane. After selling your soul to the devil, you manage to replace the damaged equipment with parts from an automatic toilet flush valve and pull off a successful demo. Is this excellence? Sure. Is this everyday excellence? Hopefully not. Stories of Firefighting make for great press, but are usually not indicators of overall excellence.

Shortly after the firefighting speech, a video was shown of an individual praising a particular developer. There were some great one line examples of this individual’s abilities – and the person was truly deserving of the award based on these alone. What got most of the video time was related to this developer’s rewrite of what was accepted as a truly terrible piece of code. We have a typical story here: Developer worked more hours in a week than most work in a month to get the rewrite completed. Is this a sign of Excellence, or is it an example of Firefighting?

My answer to this question is a resounding NO for both. If you have to work excessive hours for days/weeks/months on a scheduled project, it is the exact opposite of excellence. In industry terms, this is known as a Death March. Someone, somewhere screwed up bad. Perhaps it was the design. Perhaps it was the implementation. Maybe the fault was in the management expectations. Regardless of cause, this is a huge, flashing neon sign that something is horribly wrong. Perhaps we all need to read (or re-read) Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams by Steve Maguire. In my personal experience, EVERY project that required long hours by the developer ultimately failed for a multitude of reasons and with a multitude of negative outcomes:


  • QA is often scrunched to get the project out the door.
  • Because of the above, there are serious undiscovered bugs that get shipped.
  • The resulting code is difficult to maintain.
Although I have no personal experience with this project and its outcome, anecdotal reports from people I spoke with confirmed the above bullet points. There are plenty of references to this topic, most of which are buried in research and justifications to development methodologies known as “agile.” While describing agile methodologies and concepts is outside the scope of this entry, one interesting paper worth a read that supports my assertions is Estimation as hypothesis, by Alan Shalloway. I highly doubt that anyone would want to encourage this type of coding behavior by using it as a justification for an award! Although up until now I have covered what is NOT excellence in Software Development, but I have not covered what IS excellence of the everyday kind.

Boneman’s Principles of Software Excellence:
  • Know your customer - This is an extremely vague topic, but if you are developing software that provides simplistic configuration of widgets for Biscuit Welders, and most Biscuit Welders have a preschool education, your interface and documentation must reflect that understanding. This may involve following your customer around during one of their typical workdays to understand their job and their workflow. Any employer that does not allow, encourage, or suggest this during a new employee orientation and thereafter as required is not worth working for.

  • Know and follow best practices - These days, security is a primary concern. Does your application comply with industry best practices? Do you know that such things exist? When was the last security related continuing education session held at your organization. If this answer is greater than one month ago, the developer with the most excellence will be scheduling one – hopefully this person is you.

  • Compliance with current industry coding standards.

  • Evangelism - Are you talking up industry standards and best practices with your teammates? Are you using code reviews as opportunities for education and not as a forum to criticize? Do you even have code reviews?

  • Non-use of Programmer Quotes - You correct (harshly but constructively) any developer who utters one of the quotes found on this page because your code understand that all user input, data, or machines are evil until proven otherwise.

  • Take the blame - If you get a call from a support person, it is almost always your fault, and you admit it. Most often this is due to the lack of error checking or useful error messages in the code you wrote. Instead of merely answering the question or fixing the problem, immediately adjust the code in question to provide useful feedback to the user. While you are at it, you write a Unit Test that exhibits this behavior.

  • When you are stuck, you admit you are stuck - If you are behind schedule, you immediately admit it and ask for help. Recognizing that you or your project is in trouble is the first step, asking for help is what separates the men from the boys. Remember that you are part of a team. Even if you are the sole software developer in the organization, you need the support and understanding of your team to get through any coding crisis. This does not make you any less of a programmer, in fact, the ability to admit you need help will earn you my vote for a place on my team, anytime, and anywhere.

  • Check with the helpdesk, implementation, and training personnel for issues related to your code - Every successful pro athlete reviews his or her performance on video after the big game. Why? So the athlete understands what they did right, and what they did wrong. In the world of software, all of the above listed people are the first line of customer contact. If your code nailed the extremely complicated but infrequent widget refactoring process you stayed up late thinking about, but bombs when previewing the daily report unless the user is wearing a green hat, you need to know this, correct this, and put into place a process to prevent these simple but frequent (not to mention annoying) bugs from happening in the code you are writing today.

The above is not even close to a comprehensive list, but rather what was on the top of my head as I created it. Sadly, I can’t think of a single person that within the last six months has actually lived up to this list, including myself. It looks like some things are going to change around here – and for the better. Please feel free to add to this list in the comments below.

4 comments:

Steven Bone said...

I noticed in my referral logs that this post was nominated for the "Joel On Software" best Software Essays of 2004. I'm impressed that "schmoe" found this post enlightening enough to nominate. It is certainly not the best work on the subject that could be done, rather reflections that came to me at 1:40 AM that evening/morning. Perhaps this is what blogging is about - a slice of time or history that impacted the blogger in some way that he or she felt important enough to share with others.

The nominator mentioned that my post is similar to the "Personal Character" chapter in Code Complete 2nd Edition. Sadly, I have not completed reading that book (including chapter 33) - it keeps getting pushed aside for other books because I read the 1st edition long ago. I'll have to put the book back to the top of the queue to catch this reference. I'm sure that I'd agree with Steve McConnell's philosophy - I have in the past.

Joel publishing a collection of these essays is a good thing, especially since he is so well-respected in the community. Hopefully, he will allow some editing if this one is chosen - without having link-context some of the points don't make sense, which is typical of blogging.

I haven't read most of the other ones nominated. Perhaps I will blog on some of these after I catch up on some now mandatory reading at the expense of Steve McConnell.

Anonymous said...

Pretty good for early in the morning! Sure you didn't spend more time on it? : )
Stacy - your coworker

ttChipster said...

Steve,

Nicely put and well referenced. Why can't largish companies keep up; not with state-of-the-art but just with industry best practices.

And congratulations on the Joel_On_Software nomination.

-- Chip

Anonymous said...

The reaction to the list of "programmer quotes" is good, except for two:

# "Even though it doesn't work, how does it feel?"

That's a very valid question, particularly in prototyping. An 80% correct application that _feels_ right (ie, doesn't frustrate the user) will usually be better accepted than a 100% correct application that makes the user pull out his hair in frustration. Just so long as the question isn't "I'm not going to fix the bugs that keep you from doing your job, but aren't the UI skins really nice?"

# "Why do you want to do it that way?"

Lots of times a user will say "I need a program that does X, Y, and Z, using A, B, and C". We implement exactly what they ask for, and when they get it, it doesn't do what they wanted because we didn't know _why_ they wanted A, B, and C, or to what end they wanted to accomplish X, Y, and Z. Just so long as the question isn't really "Why do you want to do it the right way, which is too much work for me?"