RE: [scrumdevelopment] Scheduling Defect Fixes
- At the moment there is not a lot of emphasis on 'defect prevention', apart from the conventional and traditional 'code inspections', user-driven testing and good advice about how it is a good idea.
At this university, which I frankly believe to be reasonably representative of IT / CS / BC curriculum generally in universities, the unfortunate fact of the matter is that testing and 'defect prevention' is under-represented, shall we say, in curriculum. In my situation, trying to change the direction of the curriculum is a bit like steering a large ship ... it takes a long time to change course. In many countries, Thailand and Australia to my sure knowledge at least, Government Ministries of Education have a lot of say in curriculum, even at the University level. So in many respects what the education bureaucrats know and understand is what is included in the curriculum.
But I am trying! There is another professor here in the IT Engineering Faculty who teaches esentially introductory TDD, and emphasises good testing and QA practices. But he is a bit of a standout.
As for me, well, I am so busy trying to get the students to understand even the basics of iterative development, good documentation practices, thinking instead of copying, the difference between reuse and plagiarism etc. that it is difficult to introduce these things. But I try! At the moment I am starting to oversee student projects, and it is obvious to me that the first thing the students do is try to design some tables without much understanding of the business requirements. I am in a position of being able to have some influence on future curriculum, so I am as busy as a lizard drinking introducing these basic ideas. A difficult part of my job is to convince others, such as the (Java) programming mahaguru (Malay for Higher Teacher) to think about TDD, things like ANT or JUnit etc. and to get them to change their curriculum. At the same time I can't give an appearance of being 'The Wise Man from the West' ... these are competent people in their own right and in their own sphere. They do have one major drawback, and that is, most of the literature available on Agiule etc. is in English, which many of them do not understand.
Date: Mon, 31 Jan 2011 22:12:03 -0800
Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
Do you have a section of your course dedicated to defect prevention? If so, what techniques do you teach?
Many in the "Agile" and "agile" movements have tried to shift the focus to be more on defect prevention and less on defect detection. Do you cover that topic at all? If so, what do you teach on that topic?
From: Roy Morien <roymorien@...>
Sent: Mon, January 31, 2011 8:32:49 PM
Subject: RE: [scrumdevelopment] Scheduling Defect Fixes
Yes, I am sure that you can Ron, and obviously the ultimate desirable outcome is not to have bugs at all. Then the discussion on how to handle bugs becomes irrelevant and unnecessary.
But the fact is, the original posting was about how to handle bugs. This obviously meant that the poster had bugs, as awful as that may be.
So, by all means advise on how to not have bugs.
But also it must be accepted that bugs happen, or are created, or whatever euphemism is applied to that awful situation. So the best way to handle bugs needs to be discussed. It is no advice at all to say "don't have 'em" in this situation.
This is really the central theme of everything I have said ... bugs are certainly not a good idea to have, you should do everything that you can to not have them, but if it happens, 'this' is a good way to handle it.
I am, as you know, a teacher at a university. If I teach students about programming or analysis and cover the problem of code errors, bugs, defects etc. by telling the student 'OK, don't have them,! Got it? Good!' then this would not be very useful, would it?
Why is this controversial and worthy of extensive disputation and argument?
> To: firstname.lastname@example.org
> From: ronjeffries@...
> Date: Mon, 31 Jan 2011 21:42:59 -0500
> Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
> Hello, Roy. On Monday, January 31, 2011, at 9:29:29 PM, you wrote:
> > "The best solution, as Ron mentions, is probably to reduce
> > defects to such a small rate that there is no material amount of defect fixing time. "
> > Oh, I heartilly agree ... and the best solution to poverty is to
> > have more money. The best solution to poor child health is to not
> > have child illness. The best solution to traffic jams is to stop cars going on the road.
> FYVM. I can teach people how to reduce defects.
> Ron Jeffries
> Testing quality into a program is like spinning straw into gold.
> -- George Cameron.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
> <*> To visit your group on the web, go to:
> <*> Your email settings:
> Individual Email | Traditional
> <*> To change settings online go to:
> (Yahoo! ID required)
> <*> To change settings via email:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to:
Although, this is not Twitter. I really want to do a +1.>>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.
Echoes my thoughts completely. Won't have been able to put it better myself.