Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘bugs’

“We Found a Bug!” How Should Support Be Handled?

Posted by iammarchhare on 1 September 2009

Over at Agile Chronicles, Mike Cottmeyer posted “Handling Support on Agile Teams”, but as even he himself says, “This is a problem not unique to agile teams. Software organizations have been struggling with this one for years.”

Indeed, he is most correct.  How to account for time dedicated to support once the code is out in the open?  I have noticed, though, that the more seasoned the team, both as individuals and as a unit, the less defects are likely to be produced.  Yes, experience is the best teacher, but it isn’t necessarily the most efficient one.

Cottmeyer lists 3 options for dealing with defects.  Each has its strengths and weaknesses.  Personally, I think a lot on the exact method you pick is going to have a lot to do with the overall environment, the types and number of current projects and the overall effectiveness of the developers.  I use “effectiveness” as not only productivity, but experience level and ability to task switch.

That last point should not be underrated.  The ability of any individual to multitask is going to have a profound effect upon the duration and quality of their work.

However, here are some other factors to keep in mind:

  • Responsibility.  How often is Jane going to fix John’s code without resentment building up?  Is John mature enough to at least accept responsibility for his mistake and learn from it?
  • Amount and severity of defects.  Some defects can wait.  Are you getting an abnormal number of defects?  Of course, you’ll need some type of historical data to go on, but if there are an abnormal number, it might be time to do a triage or at least a special after action review.
  • Corrective to preventative measures.  It isn’t enough to just fix the immediate problem, but for the team to learn how to avoid it next time.
  • Seniority mix of the team.  I have long argued that you want to avoid all junior developers for a team.  However, you also want to avoid all senior developers on a team.  You want a mix, but no more than 50% new developers and no less than 50% experienced ones.  Why?  Because you need mentoring, coaching and the examples of the senior developers to grow the junior ones.  However, an injection of new ideas is not a bad thing, either.  Not only that, but a team of all senior developers can become an ego party.  Frankly, it is not the most efficient way to get work done, and neither is it all that entertaining.

One of the key requirements of being a manager, but especially a project manager, is flexibility.  How you deal with defects will test your skills and bend you out of shape if you allow it.

Advertisements

Posted in Software | Tagged: , , , , , , , | Comments Off on “We Found a Bug!” How Should Support Be Handled?

Defensive Programming

Posted by iammarchhare on 4 May 2009

Remember when you learned how to drive, and you had to take a course called “defensive driving”?  You learned to anticipate problems on the road instead of racing down the road assuming nothing would ever go wrong.  By driving in a manner that would put you in the best position possible should something go wrong, you often avoided anything going wrong at all.

Software developers tend to be an optimistic bunch.  Write code for that?  No problem!  Want it in a week?  No problem!  Somehow, they tend to underestimate the power of a computer to do only exactly what it is told to do, whether by their own code, someone else’s they have to interface with or the compiler.

Agile development encourages people to do their test cases up-front.  I am in complete agreement with that concept.

There are problems with that, as there are with anything in life.  In “Developers Can’t Test for Toffee!”, Kelly Waters asks, “Why is it that developers can’t test?”  Waters pretty much states it is the “can’t see the forest for the trees” syndrome.  Developers can only test for issues they think of.  They are down in the bowels of the code, so naturally testers can think of scenarios the developers have not.

Waters makes a pretty good case, I think.  However, my experience is that most developers aren’t trained to think about what goes wrong.  I remember more than one post-mortem where I would ask, “Why wasn’t this accounted for?” and the answer very often was “I never thought that [condition] would occur.”

I guess I was fortunate in that I had a professor who insisted that code ran and produced the expected result.  “Code for the error conditions first,” he used to say.  “Think about what will happen, because it eventually will, when you get in some bad data.  Don’t assume users will input valid data.”

I began to call this concept “defensive programming”.  Anticipate the problems before the best case scenario is even written.

Posted in Risk Management | Tagged: , , , , , , , , , , , , , , | 1 Comment »