Comments on: Part 2: How To Manage An Unrealistic Schedule http://www.yuwantitwhen.com/blog/2007/10/25/part-2-how-to-manage-an-unrealistic-schedule/ Practical methods for successful software management. Thu, 06 May 2010 02:07:08 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Bill Miller http://www.yuwantitwhen.com/blog/2007/10/25/part-2-how-to-manage-an-unrealistic-schedule/comment-page-1/#comment-72 Bill Miller Sat, 27 Oct 2007 12:25:33 +0000 http://www.yuwantitwhen.com/blog/2007/10/25/part-2-how-to-manage-an-unrealistic-schedule/#comment-72 CeeKay, thanks for commenting. You make a fair point, and certainly there is the potential that too many defects would add stress to the schedule, but let's assume you are there with too many defects. What do you do about it? Do you make the team feel like they failed, or do you focus on the only thing you have control on at the instant in time, and that is finding and fixing them? I'm recommending that we need to be solution oriented and focus on what we can control at that instant in time. One thing the software community needs to get a handle on is what it means to have too many defects in test? Is it an absolute number? I don't think so. I believe it's a relative number. If you write more code, you write more defects. If hypothetically we write 2 new applications, application A has 1000 lines of code and application B has 500,000 lines of code, we should expect that application B would have more defects found under test. Too often we talk about too many defects without any context. I believe too many defects is undefined without context. I plan to write more about this in my series on metrics. While I support the practice of finding defects throughout the life-cycle, I also believe there are classes of defects that are easier to find in test than the earlier phases, and the investment to completely contain defects in the earlier phases is also untenable and would result in even more elongated schedules. Sometimes too much of a good thing is bad. You can go overboard in phase containment. I do plan to address some of this in my final article on the topic, so please come back and share your points of view. I appreciate it. CeeKay, thanks for commenting. You make a fair point, and certainly there is the potential that too many defects would add stress to the schedule, but let’s assume you are there with too many defects. What do you do about it? Do you make the team feel like they failed, or do you focus on the only thing you have control on at the instant in time, and that is finding and fixing them? I’m recommending that we need to be solution oriented and focus on what we can control at that instant in time.

One thing the software community needs to get a handle on is what it means to have too many defects in test? Is it an absolute number? I don’t think so. I believe it’s a relative number. If you write more code, you write more defects. If hypothetically we write 2 new applications, application A has 1000 lines of code and application B has 500,000 lines of code, we should expect that application B would have more defects found under test. Too often we talk about too many defects without any context. I believe too many defects is undefined without context. I plan to write more about this in my series on metrics.

While I support the practice of finding defects throughout the life-cycle, I also believe there are classes of defects that are easier to find in test than the earlier phases, and the investment to completely contain defects in the earlier phases is also untenable and would result in even more elongated schedules. Sometimes too much of a good thing is bad. You can go overboard in phase containment.

I do plan to address some of this in my final article on the topic, so please come back and share your points of view. I appreciate it.

]]> By: CeeKay http://www.yuwantitwhen.com/blog/2007/10/25/part-2-how-to-manage-an-unrealistic-schedule/comment-page-1/#comment-71 CeeKay Sat, 27 Oct 2007 05:47:33 +0000 http://www.yuwantitwhen.com/blog/2007/10/25/part-2-how-to-manage-an-unrealistic-schedule/#comment-71 Hi Bill, This is a pretty good list and all contributes towards a better environment during the project even when we are not able to meet all commitments. On item 8, even while it is still better to find defects in test rather than at the customers' premises, finding too many defects in test almost ensures that you are not going to be able to meet the date. Fixing too many defects too late in the lifecycle means we introduce many more defects at that stage and finally we decide to leave quite a large number of them unresolved. So there should be enough focus on finding the issues during the reviews, development testing etc.. If too many defects get through that net, you will end up with a failed (or stressful in the least) project anyway Hi Bill,
This is a pretty good list and all contributes towards a better environment during the project even when we are not able to meet all commitments.
On item 8, even while it is still better to find defects in test rather than at the customers’ premises, finding too many defects in test almost ensures that you are not going to be able to meet the date. Fixing too many defects too late in the lifecycle means we introduce many more defects at that stage and finally we decide to leave quite a large number of them unresolved.
So there should be enough focus on finding the issues during the reviews, development testing etc.. If too many defects get through that net, you will end up with a failed (or stressful in the least) project anyway

]]>