Saturday, June 10, 2006

Defect Count is a Constant

One of the most inspirational people in software that I've come across is Jim McCarthy. I had the privilege of seeing him give a presentation, and he had a few quotes that made a lot of sense. The one that really stood out to me was
"Defect count is a constant."



This became very clear to me last week, as my team went through a Bug Bash. In 48 hours, we closed out over 400 defects, but the number of defects open with development stayed almost level. I could go into the details of the defects, such as priority, severity, category, and so on, and we did make some substantial progress, moving our average defect severity from critical to medium, but at the end of the day, all software has problems bugs defects. And this was one of the most difficult lessons I've ever had to learn:
Shipping software is an act of reality, not a pursuit of perfection.

This lesson was extremely difficult since I come from a development background, I always want my software to be perfect, to be bug-free. Unfortunately, the larger the project, the less control that you have over it. As a manager, your job is about steering the ship, and you have to trust that your staff is all rowing in the same direction. There are things you can do to get more involved with the low level tasks, and I recommend that you do, but at the end of the day, you can't spend 40+ hours per week with each member of your team (Trust me on the math, after 4 employees, this model doesn't scale). In the world of software management, you need to accept a product that is less than perfect, and understand what is critical to ship and what is not. I'm not saying that you should ship a garbage product, but at the end of the day, if a new feature isn't ready, you can probably cut it, ship the release, and your world will not come to an end. Note the exception list here is long, like if the feature is contractually committed, or highly marketed, or the center piece of your release, etc...

I added some links at the bottom for more information about Jim McCarthy for your reading pleasure.

Jim McCarthy - I highly recommend that anyone involved with shipping software, especially in any leadership position, should check out Jim's book and video if you can get your hands on it.

Technorati : , , , ,

2 comments:

Anonymous said...

As a software developer/QA analyst I definately don't want to ship a non-perfect product. Especially because I just got out of school (a year ago) and every assignment I handed in (except one) was perfect.

I understand where this comes from and I believe that you are correct. I am currently working on a extremly large custom application, on which I am in the role of QA Analyst. This is tough for me because I see the mistakes and just want to correct them. But I am not allowed, because it's not my current role. (I will be moving into a developer role when the project goes live).

Thanks for the heads up that there will be imperfection.

--doc0tis

Anonymous said...

There is a huge gap when we talk about SW-Product developmet to Applicatrions develoment.

For sure, Product development expericnes are same as the blogger and his referred resources.

Though, from the Microsoft development background I think, always you have to establish objectives and golas clear and don't get too much excited when you discover some good technique or feature for some thing. Have your approach for objectives in an iterative aproach and always guage the strentgh and weekness of the team regulary, as performance indicatros for team have been as chaging as date and time of the calender.

Be optimistic while leading a team and be pesimistic when reporting to Management. Feasibility always should be coveyed upfront.

There can many points that come to my mind but long story short, achive a given functionality one at a time and assemble all pieces together timely.