Topic: Bugs

Bugs can’t be estimated

John McCaffrey, Tuesday, May 5, 2009 @ 11:37 pm

In an earlier post about the benefits of Agile and Scrum, I made a statement that bugs by their nature are not the same as normal features, and I wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a slightly different take on the subject.

My definition of a bug is: A feature that was specified, and you attempted to deliver, but is not working according to your intentions. (ie. "I thought it WAS saving to the database")

Not a bug: A feature or variation that you hadn't intended to create in the first place. ("Oh, I didn't know it was supposed to do that when you clicked the back button")

And with that understanding I say "Bugs can't be estimated"
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Estimating Bugs and the Complex Behavior of Simple Systems

Dietrich Kappe, Monday, February 9, 2009 @ 2:01 pm

One of the bitter consolations of mathematical Computer Science is that we can demonstrate that applying algorithms to analyze algorithms is a largely fruitless task. It starts with the halting problem (can we write a program that takes a program as it's input and determines whether that program halts on all inputs) and goes on from there. The proof is by contradiction and -- like most "assume not" proofs -- is largely unsatisfying, i.e. it doesn't construct anything useful that you could apply to other problems. As Professor Herstein once told me in undergrad algebra, "Kappe: assume not assume not."

That's one of the theoretical underpinnings of why some software bugs are so hard to detect and fix; in a large system, automatically diagnosing bugs is akin to solving the halting problem. But what if we just try to solve this problem for a really small subset of programs? Well, first, it would have to be a really small subset. And second, even with very simple systems, answering questions about correctness, such as "does it halt," can be surprisingly difficult.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Scrum defined in under 10 minutes

John McCaffrey, Thursday, January 22, 2009 @ 4:26 pm

Hamid Shojaee from www.axosoft.com put together a great video to introduce the core concepts of scrum and Agile practices called "Scrum in under 10 minutes"

I really like what he said particularly the focus on the importance and simplicity of the burndown chart which helps to :

• Visually show the hours remaining, and help anyone see "are we there yet?"

• Allows decision-makers to make adjustments if needed

A simple burndown chart quickly shows the impact of some of the most common efficiency killers or blockers

1.    late-breaking requirements changes
2.    waiting for business decision
3.    waiting for tech. partner (ssl keys, ops. vendor, etc)

He mentioned the standup, but didn't cover the 3 questions (What did you do?, What are you going to do? What do you Need in order to accomplish it?), or the idea that only people that have work can speak (Chickens vs. pigs)

I also liked his take on bugs, that you should plan a sprint to tackle them, and any bugs that come up during a sprint should be tackled immediately.

That's actually something that a lot of teams struggle with, "How do you plan for and estimate the time necessary to fix bugs?"

I always say Bugs Can't be estimated. While you may be able to plan how much time you will allocate to working on bugs, you can't really estimate how long it will take to fix bugs unless you have already looked at them, and have figured out the problem. From my point of view its the "looking at it and figuring out what's wrong", that takes the longest, and is the part that needs to be accounted for.

How do you plan for bugs?
Do you let bugs accumulate and then have a final sprint before a Release where you tackle all of the bugs? (How would you know that you can fix all the bugs in time for the release?)

Do you tackle all High-Priority bugs as soon as they come up, and leave the medium and small priority bugs for later?

Do you have a 'zero-bug' policy, where you fix any bugs that are opened?

UPDATE: I've expanded on this discussion a little more in a new post Bugs Can't be estimated, and after having some discussions around how best to plan for bugs, I was asked to do a last minute Security Analysis, and I wrote a post about How to avoid the last minute security review, and I think that the planning part can actually apply to how you manage a big list of bugs as well.

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development