Bug 103795

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Monday 23 May 2005 10:13, James Richard Tyrer wrote:
> 
>>(perhaps to the point of being boring).  If my blogs seem vehement, it
>>is because I do care about this (is that bad).
> 
> 
> caring is not bad, being rude is not healthy for a community's wellbeing.
> 
There is a thin line between being direct and being rude.  It is never 
my intention to cross it.  I realize that I am very direct about things 
-- this is part of the engineering culture.  The example I give is that 
if a fellow engineer tells you exactly what is wrong with my design, I 
should take this as being helpful.  I have noticed that KDE developers 
tend to take this as personal criticism (it is criticism, but not 
personal).  Engineers are trained to find the faults in design and we 
tend to be rather direct about it.

> btw, blogging happens on the web. blog is a mutated version of "web log". =) 
> on an email list, where it gets pushed out to everyone subscribed, we usually  
> call it "ranting". =)
> 
> 
>>The major presumption appears to be that we don't have enough volunteers
>>to do the *extra* work to implement the ideas I have advocated.
> 
> 
> it's not about _extra_ work, it's about imposing a different set of work. 
> that's the unrealistic part given hard reality. you need to find people, 
> preferably starting with yourself, to take up that different set of work. if 
> it improves efficiency, everyone wins.
> 
The thing is that for TQM to work, everyone needs to be responsible for 
testing their own work.  Preferably, they would do the testing 
themselves, but it should also work if they directed the testing.  If we 
are going to the latter, we would need volunteers to work with specific 
developers to help with the testing.
> 
>>So, try to understand that if sufficient testing had been done at the
>>time this minor change was made to: kdelibs/kio/kio/kdirlister.cpp to
>>prevent the introduction of the bug into the code base that all of the
>>time spent bug hunting and handling the bug reports on BugZilla would be
>>saved.  This seems like a simple concept.  This would not have taken
>>less work, it would have taken less work.
> 
> yes, if we were perfect we'd have fewer corrections to fix.

It is not need to be perfect, but 6 sigma does mean almost perfect 
quality.  Clearly we all make mistakes when coding.  The objective is to 
find the mistakes *before* rather than *after* the mistakes become part 
of our code base.

> if we had 100% code coverage with our tests, we could identify most of our 
> coding errors quickly. (note that test coverage for GUI's is notoriously 
> unsolved) 

I am not saying that it is easy to implement.

> if we had people running those tests for each changeset, we would catch the 
> bulk of errors.
> 
> as you can see, this is new work. it may result in an overall greater 
> efficiency, but it is new process. since we won't become magically perfect, 
> we could use people who are writing test suites and people who are running 
> them. who is going to do that?
> 
As I said, it is best if the person that writes the code does the 
testing.  I don't know how much testing various developers do before 
submitting a patch.  Obviously it is axiomatic that if a small change 
introduces a serious bug into the code base that they didn't do enough. 
  At the app level all that is probably needed is to build the app and 
see how the changes work.  I realize that this is not as simple with 
libraries because you don't know exactly what it might effect.
> 
>>It has been suggested that I should recruit people to test other peoples
>>code.  This is not about testing other peoples code, it is about testing
>>you own code.  You can work in a group, but that probably isn't as
>>efficient.
> 
> yes, it is more efficient, for many reasons. beyond parallelization, look up 
> "pair programming techniques" for some other reasons. but beyond efficiency, 
> there's REALITY to be faced. we can not and will not force everyone to follow 
> some arbitrary development system. that means we need to augment that 
> development system. 
> 
Yes I know that that is the culture here that nobody tells anyone what 
to do.  I have to ask if that is really working?  IAC, what we can have 
is a gate keeper -- we can't force people to right good code, but that 
doesn't mean that we have to accept bad code into the code base.  We can 
provide methodology to prevent bad code from being committed into the 
code base and hope that coders will use it.

> i'd go so far sa to say that writing and running tests (and then triaging that 
> information) is something that can be done by far more people than the actual 
> original development. so from a resource expenditure point of view, it would 
> be great to spend that wider skill pool on tasks appropriate for the 
> abilities.
> 
As long as the coder was involved it it, it should work.  Having others 
do the testing is probably appropriate for trying to hunt down quality 
problems caused by changes to libraries, but the way I work on the 
application level couldn't be done by someone else.  I build and try a 
lot and it wouldn't be practical for someone else to do this till felt 
that I was done.  Then it would be helpful for others to try the patch 
and see how it worked.
> 
>>It is correctly stated that BugZilla is overloaded and that we don't
>>have enough people to maintain it.  This is correct.  I am suggesting
>>that we go at this from a different direction.  If we can prevent the
>>introduction of bugs into the code base, we wouldn't have a many reports
>>on BugZilla.
> 
> and yet the amount of effort required is still there. Bugzilla is an 
> interesting data point because it's EASIER than what you suggest and already 
> has buy-in, yet doesn't work because many people who claim to care about 
> KDE's quality don't do much about it.
> 
Yet despite the lack of a work force to maintain BugZilla, I have to say 
that I quit working on it because, despite what you say, a few people 
were very critical of my work.  They didn't try to help me improve, they 
just bitched about it -- some made personal insults.

IAC, the issue with BugZilla as I see it is the nightmare scenario where 
the number of bug reports continues to increase faster than they can be 
resolved.  This is clearly not an acceptable situation.  Clearly, 
catching the bugs before they enter the codebase is one way of attacking 
this problem.
> 
>>It was also suggested that I should lead by example.  I think that this
>>is a good method which I try to practice.  I don't exactly know how to
>>do that in this case since I sit alone at my computer and use the
>>methods which I advocate. 
> 
> why not pick an area of KDE that has poor test suite coverage and write tests?
>  
That wouldn't be coder directed testing.  If you want others to do the 
testing for coders, there needs to be some organized structure.
> 
>>So, if there is anyone out there with an open mind (that does not
>>express the usual reactionary response to a new idea) that would like to
>>discuss this, please post your comments.  I also ask that those of you
>>with a closed mind set please not take my word for anything.  Instead,
> 
> 
> just because i don't agree with some of what you say does not mean i don't 
> have an open mind. 

You are absolutely correct.  People that are willing to discuss things 
do  have an open mind.  Even if someone tells me that I am wrong and 
explains why I am wrong, they have an open mind.

It is people that presumptuously tell you that you have to be wrong, and 
tell you that because you said things they don't like that you were 
added to their "kill file" -- they have a closed mind set.

i truly hope that isn't what you were trying to get at  here.

Not at all.

-- 
JRT