Quality is cheaper
Phlip
The hardware world underwent a revolution with Shewhart and Deming's
process quality control practices.
Briefly, here's one common practice they debunked. A tool operator
produces parts, and drops them onto a conveyor belt. Some way down the
belt, a "quality control" operator picks up each part, measures it,
and tosses the ones that are out of tolerance.
In this model, managers expected to get higher yield by ordering the
tool operator to go faster, and by hiring more QC operators to throw
away the increased defect rate. The tool is the expensive part, so
making it go faster returns value on its investment.
This practice has a parallel in some modern software shops (such as
Microsoft's). A programmer writes code, and a test engineer (in
another office) picks up each integration and writes unit tests for
it.
This practice creates errors under the assumption they must be
created, so they must be removed downstream. It overproduces, and then
censors out the bad parts.
Shewhart and Deming changed this practice, for hardware. They decreed
that if the tool operators themselves can learn to calculate a few
statistical formulas, they can rate the odds that their tool will
yield product out of spec. Then, when those odds are safely under some
threshold, say 1 in ten million, the company can safely take the QC
people off the conveyor belt. The entire process now operates with
much less industrial waste.
This is the "quality is cheaper" principle.
Programming is a design activity. Our hard drives themselves take care
of the statistical aspects of production for us, in their own way. But
these parallels between waste in production efforts, and waste in
design efforts, are compelling.
They indicate we should seek ways to waste less. In a design effort,
chronic bad design is waste, as are firefights, long bug hunts,
operating the debugger to program, and long hours. So we use
TestDrivenDevelopment to literally stop the bugs before they start.
But in a design space, we can't use statistics, because each element
of product >should< be immeasurably different from each other. So we
tune our production tools using another entire human being: Pair
Programming.
--
Phlip
http://www.greencheese.org/DontPlanDesigns
-- Appears that VIM is internationalized...
May I ask what's the point? --
Ron Jeffries
>The hardware world underwent a revolution with Shewhart and Deming's
>process quality control practices.
How would the reasoning in this report apply to the notion we were discussing in
the other group, about shipping the software only once a year?
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Keith Ray
phli...@yahoo.com (Phlip) wrote:
[...]
> They indicate we should seek ways to waste less. In a design effort,
> chronic bad design is waste, as are firefights, long bug hunts,
> operating the debugger to program, and long hours. So we use
> TestDrivenDevelopment to literally stop the bugs before they start.
>
> But in a design space, we can't use statistics, because each element
> of product >should< be immeasurably different from each other. So we
> tune our production tools using another entire human being: Pair
> Programming.
An interesting comment in Weinberg's book about "Reviews, Walkthroughs
and Inspections" -- reviews are not for defect detection, they are for
defect prevention. Initially, reviews find lots of defects, but the
engineers soon learn not to make defects. Managers are tempted to drop
reviews, but that would be bad -- reviews provide other benefits, like
spreading knowledge about good programming practices.
Everything said about reviews applies to pair programming, and more...
pair programmers help each other brainstorm, and not only prevent
defects from lasting more than a few seconds, they can prevent wasting
an entire day or week going down the wrong path.
--
C. Keith Ray
Phlip
> An interesting comment in Weinberg's book about "Reviews, Walkthroughs
> and Inspections" -- reviews are not for defect detection, they are for
> defect prevention. Initially, reviews find lots of defects, but the
> engineers soon learn not to make defects. Managers are tempted to drop
> reviews, but that would be bad -- reviews provide other benefits, like
> spreading knowledge about good programming practices.
That is why this test should have gone to 2 or 3 iterations:
http://www.ipd.uka.de/~muellerm/publications/ease02.pdf
With round-trip feedback, the Test-First group will kick the other group's
ass.
--
Phlip
http://www.greencheese.org/PeaceAndCalm
"The trouble with the French is they don't have any word for
entrepreneur." --George W. Bush
Phlip
> On 4 Feb 2003 18:46:34 -0800, phli...@yahoo.com (Phlip) wrote:
>
>>The hardware world underwent a revolution with Shewhart and Deming's
>>process quality control practices.
>
> How would the reasoning in this report apply to the notion we were
> discussing in the other group, about shipping the software only once a
> year?
It's harmless. You should not tune your machine once per data point - that's
"over control". You should measure a sample of each run, trend the runs
over time, and only tune the machine after a statistically significant
trend or pattern appears.
Delayed feedback (measuring the product very far down the assembly line) is
bad. Delayed tuning is good.
--
Phlip
http://www.greencheese.org/ParodyMode
-- All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy. --
Frank Andreas de Groot
But it doesn't apply to hardcode coding.
Example: I am working on quite a complex encoder. In order to test it, I need a decoder.
But the decoder simply is the same as the encoder, only the data goes "backwards" :o)
When the decoder works, so does the encoder. So when I have written my test,
I have written my program. I can't write a test before I have written a correct program, otherwise
my test would be wrong.
Most of XP is good for newbie database programmers, only some applies to real programming.
(You know, the kind of programming with 4-dimensional arrays ;o).
There is not a soul who can even UNDERSTAND what I'm doing here, because the program does not merely involve
high-tech coding, it also involves some unusual and complex IDEAS that need to be expressed in code,
but a code buddy would have to be able to understand the IDEAS first behind the code.
I'm writing AI history, and where do I find a "code buddy" who will look over my shoulder and tell me
what I'm doing wrong? I have tried one to use a "code buddy". I had written an anti-alias routine
that was obviously so complex that the people in the BASM n.g. didn't even understand it.
(you can look up the source on Google)
Some told me it couldn't work, others told me it was slower than some alternatives, etc.
Code buddies are useles in some cases, as are "test first" scenarios.
Even if I had 5 Peter Below's, it wouldn't help me in my really hard cases, honestly.
I would prefer a good Thai double soap-sandwich massage to a code buddy any time.
Phlip
> This "test first" idea is fine when you are doing database stuff.
> But it doesn't apply to hardcode coding.
But this is the "XP is for newbies" argument. There are those who try to
argue "XP only works for senior gurus with the expertise needed to survive
bad process." >sigh<
> Example: I am working on quite a complex encoder. In order to test it, I
> need a decoder. But the decoder simply is the same as the encoder, only
> the data goes "backwards" :o) When the decoder works, so does the encoder.
> So when I have written my test, I have written my program. I can't write a
> test before I have written a correct program, otherwise my test would be
> wrong.
Read the TDD material. You don't write the whole test. Surely you can write
an encoder and a decoder that pass thru one bit. Close the loop; then add
features to the loop.
> Most of XP is good for newbie database programmers, only some applies to
> real programming. (You know, the kind of programming with 4-dimensional
> arrays ;o).
I have never done TDD on newbie stuff. Mostly advanced user interfaces that
display and manipulate topological manifolds occupying an arbitrary number
of dimensions. Also fractals. Oh, yeah - there was a visual language editor
too. And a leading-edge Wiki.
> There is not a soul who can even UNDERSTAND what I'm doing here, because
> the program does not merely involve high-tech coding, it also involves
> some unusual and complex IDEAS that need to be expressed in code, but a
> code buddy would have to be able to understand the IDEAS first behind the
> code.
Is this supposed to be an argument >against< pair programming?
> I'm writing AI history
Last time I did that, the space itself required pair programming, >exactly<
because we couldn't risk the code getting away from the team. Missing a day
of work was like missing a karate lesson - you get creamed during the next
one.
I'm not sure what you think a "code buddy" is, but it doesn't sound like two
people writing one program. How do you expect to be able to explain things
to a stupid computer if you can't explain them to a peer?
> I had written an anti-alias routine that was
> obviously so complex that the people in the BASM n.g. didn't even
> understand it. (you can look up the source on Google)
Right. Two people writing one program always produce code simpler (meaning
more elegant) than the simplest intersection of the code that either of
them could alone. An AI guy should understand how these kinds of forces
push down inside a phase space of potential designs.
You have adequately underscored the point "complexity is easy to add and
nearly impossible to remove." That's why eXtremos practice adding
complexity in the tiniest, most aggressively reviewed snips. Even if it's
just a newbie project.
--
Phlip
http://clublet.com/c/c/why?ZenoBuddhism
-- MCCD - Microsoft Certified Co-Dependent --
Frank Andreas de Groot
> argue "XP only works for senior gurus with the expertise needed to survive
> bad process." >sigh<
But what is >wrong< with my argument?
> Read the TDD material. You don't write the whole test. Surely you can write
> an encoder and a decoder that pass thru one bit. Close the loop; then add
> features to the loop.
What makes you think that in my particular application I can "surely" pass one bit
through my encoder/decoder? In order to "pass one bit", I have to write both the decoder and decoder first.
And it works not by single bits. Your theories do not apply to my practice.
> I have never done TDD on newbie stuff. Mostly advanced user interfaces that
> display and manipulate topological manifolds occupying an arbitrary number
> of dimensions. Also fractals. Oh, yeah - there was a visual language editor
> too. And a leading-edge Wiki.
User interfaces are elementary. Pictures, buttons and events. That's not programming,
that's drag & drop with some simple code hooked up.
Fractals are extremely simple recursive formulas.
> Is this supposed to be an argument >against< pair programming?
Nope. I just say that there are cases that pair programming is utterly useless,
even detrimental (it would get me out of "the zone").
> I'm not sure what you think a "code buddy" is, but it doesn't sound like two
> people writing one program. How do you expect to be able to explain things
> to a stupid computer if you can't explain them to a peer?
Very simple, I understand the idea and I know how to program it.
Therefore, no need to try to explain it to a code buddy who would niehter understand it,
not be able to program it. I mean, the guy who invented fractal compression, do you really believe
he got himself a code buddy? ROTFL.
Do you think the guy who invented wavelet compression, do you think he got himself a code buddy?
Most of the coding is optimizations anyway. Granted, you could use an informed brainstormer, not a code buddy.
> Right. Two people writing one program always produce code simpler (meaning
> more elegant) than the simplest intersection of the code that either of
> them could alone. An AI guy should understand how these kinds of forces
> push down inside a phase space of potential designs.
I think you have no clue what you are talking about. My code was very elegant, and therefore
25% faster than code that looked less complex. To me it looked very elegant and it was the fastest
algorithm. I can't help it that database drag&droppers like yourself did not understand it.
Getting a clueless codebuddy to fuck the code up so he could understand it, would have been
disastrous.
> You have adequately underscored the point "complexity is easy to add and
> nearly impossible to remove." That's why eXtremos practice adding
> complexity in the tiniest, most aggressively reviewed snips. Even if it's
> just a newbie project.
That's wonderful for database drag & droppers who just come from school.
In fact I think XP is manna from heaven for you guys.
I have been doing most XP practices for the past 2 decades anyway, but I object
to the notion of XP being the magic cure-all. Some aspects work only for certain
projects and/or certain people. With very complex projects, done by very competent people,
some XP practices are of very limited value.
XP practices are preventions for certain problems. When some problems do not occur, with certain people
and certain projects, adding those particular XP practices will do more harm than good.
Rules, like religion, is for people who NEED them.
Laurent Bossavit
> I need a decoder.
I don't see why that should necessarily be true. Can you elaborate ?
> There is not a soul who can even UNDERSTAND what I'm doing here
There are those who believe that you only understand something once
you are able to teach it.
Frank Andreas de Groot
> > Example: I am working on quite a complex encoder. In order to test it,
> > I need a decoder.
>
> I don't see why that should necessarily be true. Can you elaborate ?
See my statement below :o)
> > There is not a soul who can even UNDERSTAND what I'm doing here
>
> There are those who believe that you only understand something once
> you are able to teach it.
Everybody is free to have their own religion.
And why on earth should I teach someone my trade secrets and let them
sit next to me and interfere with my work?
John Roth
"Phlip" <phli...@yahoo.com> wrote in message
news:63604d2.03020...@posting.google.com...
Also known as "Japanese Management." Factories that run this way
look quite different from old-style American factories. There are two
key differences. One is that any assembly line worker is **required**
to stop the process when he detectes a problem. The other is that the
on-site engineering staff can change the process around any way they
need to to eliminate the problem.
> Programming is a design activity. Our hard drives themselves take care
> of the statistical aspects of production for us, in their own way. But
> these parallels between waste in production efforts, and waste in
> design efforts, are compelling.
>
> They indicate we should seek ways to waste less. In a design effort,
> chronic bad design is waste, as are firefights, long bug hunts,
> operating the debugger to program, and long hours. So we use
> TestDrivenDevelopment to literally stop the bugs before they start.
The critical element, AFIC, is that the code committed to the repository
should be production quality code. That's the "don't put the bugs in
the code in the first place" part.
> But in a design space, we can't use statistics, because each element
> of product >should< be immeasurably different from each other. So we
> tune our production tools using another entire human being: Pair
> Programming.
That doesn't match what I have seen. If we apply the *principles* I
mentioned above, what we find is that *everyone* is responsible for
reporting process problems when they find them, and then the process
gets fixed to eliminate the problem.
John Roth
John Roth
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:1k014v835b194p7ms...@4ax.com...
> On 4 Feb 2003 18:46:34 -0800, phli...@yahoo.com (Phlip) wrote:
>
> >The hardware world underwent a revolution with Shewhart and Deming's
> >process quality control practices.
>
> How would the reasoning in this report apply to the notion we were
discussing in
> the other group, about shipping the software only once a year?
I don't think it does. The point I see here is that the process produces
a certain
level of quality. The "once a year" people generally need a higher level
of quality,
so they have to do additional, after the fact, testing.
The two questions that really need to be asked are:
1. How do you improve the process so the additional testing is
unnecessary?
2. How do you know that you've done it, when you have very small sample
sizes?
John Roth
John Roth
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-8E...@netnews.attbi.com...
> In article <63604d2.03020...@posting.google.com>,
> phli...@yahoo.com (Phlip) wrote:
> [...]
> > They indicate we should seek ways to waste less. In a design effort,
> > chronic bad design is waste, as are firefights, long bug hunts,
> > operating the debugger to program, and long hours. So we use
> > TestDrivenDevelopment to literally stop the bugs before they start.
> >
> > But in a design space, we can't use statistics, because each element
> > of product >should< be immeasurably different from each other. So we
> > tune our production tools using another entire human being: Pair
> > Programming.
>
> An interesting comment in Weinberg's book about "Reviews, Walkthroughs
> and Inspections" -- reviews are not for defect detection, they are for
> defect prevention. Initially, reviews find lots of defects, but the
> engineers soon learn not to make defects. Managers are tempted to drop
> reviews, but that would be bad -- reviews provide other benefits, like
> spreading knowledge about good programming practices.
I tend to think Weinberg is reaching a bit here. Alistair Cockburn
says that XP is a "high discipline" process - it needs people who can
take
a disciplined approach to what they're doing. A high discipline process
needs a high discipline manager.
A manager who's attitude is: "Get it out, and we'll clean up the mess
later," isn't going to be able to run an XP shop effectively, unless his
goal is to run it into the ground. A manager who's attitude is that
everything
one does needs to be examined continuously can run an XP team very
effectively.
John Roth
David B Lightstone
"John Roth" <john...@ameritech.net> wrote in message
news:v41vr9c...@news.supernews.com...
The statement has much better impact when you realize that there is an
obligation to immediately fix the reported problem!
The philosophy will never work for software process development. Reported
process problem are by definition either: (1) A misapplication of the
process; (2) The disruptive influence of a troll
Ron Jeffries
wrote:
>Very simple, I understand the idea and I know how to program it.
>Therefore, no need to try to explain it to a code buddy who would niehter understand it,
>not be able to program it. I mean, the guy who invented fractal compression, do you really believe
>he got himself a code buddy? ROTFL.
You seem to me to be speaking from inexperience with pair programming.
Do you ever have any bugs in your program? Does it ever fail to compile?
Ron Jeffries
wrote:
>Everybody is free to have their own religion.
>And why on earth should I teach someone my trade secrets and let them
>sit next to me and interfere with my work?
You shouldn't. You should keep on doing what you are doing. And you might also
want to recognize that what you're doing is uncommon.
David B Lightstone
"Frank Andreas de Groot" <nos...@nospam.org> wrote in message
news:uV30a.24258$Rc7.3...@news2.e.nsc.no...
> > But this is the "XP is for newbies" argument. There are those who try
to
> > argue "XP only works for senior gurus with the expertise needed to
survive
> > bad process." >sigh<
>
> But what is >wrong< with my argument?
Nothing you just got a response from Philp, by definition, it will be
biased and evasive
Phlip
> This practice creates errors under the assumption they must be
> created, so they must be removed downstream. It overproduces, and then
> censors out the bad parts.
For example, some tools on the line like to produce nothing but bad parts,
just to see QA squirm with them.
The solution is to simply never measure their output. Retire the tool
itself.
This is why I never read certain posts. Sorry.
--
Phlip
http://www.c2.com/cgi/wiki?RatAndTuyen
-- Bad nanoprobe! Bad! --
Keith Ray
> <nos...@nospam.org>
> wrote:
>
> >Everybody is free to have their own religion.
> >And why on earth should I teach someone my trade secrets and let them
> >sit next to me and interfere with my work?
I wouldn't want someone with that attitude working for me.
Richard MacDonald
> On Wed, 5 Feb 2003 11:43:16 +0100, "Frank Andreas de Groot"
> <nos...@nospam.org> wrote:
>
>>Everybody is free to have their own religion.
>>And why on earth should I teach someone my trade secrets and let them
>>sit next to me and interfere with my work?
>
> You shouldn't. You should keep on doing what you are doing. And you
> might also want to recognize that what you're doing is uncommon.
>
While we recognize that your attitude is, in fact, very common.
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> > On Wed, 5 Feb 2003 11:43:16 +0100, "Frank Andreas de Groot"
> > <nos...@nospam.org>
> > wrote:
> >
> > >Everybody is free to have their own religion.
> > >And why on earth should I teach someone my trade secrets and let them
> > >sit next to me and interfere with my work?
>
>
> I wouldn't want someone with that attitude working for me.
obviously you are not working on something that could be patented
Phlip
> What makes you think that in my particular application I can "surely" pass one bit
> through my encoder/decoder? In order to "pass one bit", I have to write both the decoder and decoder first.
> And it works not by single bits. Your theories do not apply to my practice.
You are so smart that you are capable of writing the kinds of programs
that you are not smart enough to write incrementally.
Glad I ain't that smart.
> User interfaces are elementary.
Right. And I can do the elementary kind, too.
If a UI is so simple, does the interior of your encoder/decoder have
one too? Can it illustrate the activities of the dataflow in
real-time? (This topic is "software visualization", programs that
display the activities of algorithms inside programs.)
If your program's algorithm has no UI, how easily do you think you
could add one? Could you drag an "encoder control" off a tool bar and
drop it on a window, and then just wire it up? Could this control send
commands back into the algorithm? How long before this simple code
breaks? How would you know it broke?
Remainder snipped unread.
--
Phlip
http://www.greencheese.org/MakeItSo
-- Because I'm smarter than the average firewall, Booboo! --
Frank Andreas de Groot
Yes, when I have made a typo.
This is why I use Delphi.
Compiles a huge program in 1 second on my machine.
So it takes 2 seconds to fix the typo.
As for bugs, no-one would be able to fix them but myself.
Frank Andreas de Groot
> I wouldn't want someone with that attitude working for me.
> --
> C. Keith Ray
I would not want to work for someone like you either.
And as a matter of fact, I do not work for anyone.
Frank Andreas de Groot
news:HMa0a.1863$503....@newssvr19.news.prodigy.com...
>
> obviously you are not working on something that could be patented
..or worse, something unpatentable that could make you rich..
Phlip
> And why on earth should I teach someone my trade secrets and let them
> sit next to me and interfere with my work?
Do your stakeholders know you deliberately run with a Truck Factor of 1?
This sounds like just a Job Security issue to me.
--
Phlip
http://www.greencheese.org/LucidScheming
-- In business always remember:
The customer is always funny! --
Mike Stockdale
chance to say 'I'm smarter than everyone else' - which doesn't
particularly enlighten a discussion of software engineering.
Anyway, XP is a collection of techniques (some I really like, some I'm
still undecided on) to make *teams* of developers more productive, so
the rest of us can work on the backlog of software that *you* can not
fit into your busy schedule.
Phlip
> As for bugs, no-one would be able to fix them but myself.
Hmm. The title of the thread has been "Quality is cheaper", for quite
a while now.
So how (besides excusing yourself from any review) do you keep your
quality cheap? How do you avoid having the bugs in the first place?
--
Bill Deming
Guillermo Schwarz
output, or as you put it, it is not about writing f and f^-1 to see if one
undoes what the other does. Although TDD may USE that property, it is more
about finding the simplest test data, making f pass the test data and then
finding the next complex test data, so that you need to modify f to pass
that test WHILE AT THE SAME TIME you run all the other tests that f passed
before to be sure there is no regression.
Let us suppose your complex decoder is rot-13. You select the simplest test
data, which is of course the empty string. You first start with only the
empty string and the result must be an empty string. THIS IS AN IMPORTANT
TEST CASE. Then you select a string with only one character, for example 'a'
and you should get 'a' + 13, while at the same time the decoder should get
'a' + 13 and return 'a'. You can do the same with all the possible values in
a byte. Then you can add support for unicode. Then you can add support for
UTF-8. etc.
I hope you get it now that TDD is about test data, not about writing the
software twice.
Guillermo.
"Frank Andreas de Groot" <nos...@nospam.org> escribió en el mensaje
news:3Q10a.19190$CG6.3...@news4.e.nsc.no...
Guillermo Schwarz
that "normal software development", but it has the following flaws:
1. It did not specify what methodology followed the control group. If they
followed DSDM, code reviews, six sigma, clean room, etc. that would make a
big difference that if they just coded-and-fixed, copied and pasted code and
then asked other people to test the software.
2. TDD is not necessarily good if it is not applied correctly, that is if
the tests cases do not try to find all border conditions.
3. TDD is probably not that good for only one class. In my experience it
takes at least 6 classes for TDD to be useful enough, because the lost time
programming the tests is recovered when the whole system becomes more stable
because of all the tests that are run. That is the performance gain when
compared with teams that do not write tests or that write them sparingly.
The tests for the other classes were not writtten by the students, so
probably they had no chance to make sure if the code they wrote was tested
in all border conditions, because they didn't know what the border
conditions were.
4. They probably didn't use NoUnit or the like to see which tests they
needed to create. Given that they had a whole hierarchy tree to test, it
would have useful to run that too.
Cheers,
Guillermo.
"Phlip" <phli...@yahoo.com> escribió en el mensaje
news:Xu00a.709$QH3.76...@newssvr15.news.prodigy.com...
> Keith Ray wrote:
>
> > An interesting comment in Weinberg's book about "Reviews, Walkthroughs
> > and Inspections" -- reviews are not for defect detection, they are for
> > defect prevention. Initially, reviews find lots of defects, but the
> > engineers soon learn not to make defects. Managers are tempted to drop
> > reviews, but that would be bad -- reviews provide other benefits, like
> > spreading knowledge about good programming practices.
>
> That is why this test should have gone to 2 or 3 iterations:
>
> http://www.ipd.uka.de/~muellerm/publications/ease02.pdf
>
> With round-trip feedback, the Test-First group will kick the other group's
> ass.
>
> --
> Phlip
> http://www.greencheese.org/PeaceAndCalm
> "The trouble with the French is they don't have any word for
> entrepreneur." --George W. Bush
>
David B Lightstone
"Mike Stockdale" <MikeStock...@syterra.com> wrote in message
news:IQf0a.85291$c41.2...@news2.telusplanet.net...
> Frank Andreas de Groot wrote:
> >>I wouldn't want someone with that attitude working for me.
> >>--
> >>C. Keith Ray
> >
> >
> >
> >
> > I would not want to work for someone like you either.
> > And as a matter of fact, I do not work for anyone.
It is a statement that C Keith Ray would not be a suitable manager. This
partly do to the nature of the application, but I suspect mostly because he
lacks the skills of a manager. Why he is attempting to create an
environment of fear (as a mechanism to influence workplace behavior) is
beyond me.
Ron Jeffries
wrote:
>> Does it ever fail to compile?
Again, I don't think you should pair program. But if you did, your pair would
surely learn a lot and be able to help in many areas. I presume that not every
line of your program is unintelligible to people of only normal intelligence?
Guillermo Schwarz
"David B Lightstone" <david.lightst...@prodigy.net> escribió en el
mensaje news:x780a.1676$kT4...@newssvr19.news.prodigy.com...
>
> >
> > That doesn't match what I have seen. If we apply the *principles* I
> > mentioned above, what we find is that *everyone* is responsible for
> > reporting process problems when they find them, and then the process
> > gets fixed to eliminate the problem.
>
> The statement has much better impact when you realize that there is an
> obligation to immediately fix the reported problem!
Do you mean that the problem is not even evaluated first to see if the
search for the solution is economically sound?
Do you mean the design of the solution (the new process) is not evaluated
first before implementing it?
I bet both answers are "No". There is always evaluation, but how much? If
the new process is slower and doesn't achieve more quality, we can always go
back to to the old process, can we?
>
> The philosophy will never work for software process development.
Can you back your statement with hard data?
> Reported
> process problem are by definition either: (1) A misapplication of the
> process; (2) The disruptive influence of a troll
Where did you see that?
Processes which are followed by one individual are non-processes. Any
non-trivial process requires at least the verification of a senior.
For example in XP:
1. Customer starts the process by asking for a user story.
2. Developer estimates how long it would take or asks that the user story be
divided.
3. Customer divides the user story if required and goes back to 1.
4. Customer presents acceptance test for the user story.
5. Developer pairs with another developer to implement the user story. Both
review each other design and code.
6. They write unit tests before writing the code, so that they must pass
both unit and acceptance tests before check-in.
7. Once checked-in, cruise control will verify that the project still
compiles and that all tests pass.
8. At the end of the iteration, if a user story is not implemented it is
rescheduled for the next iteration. The actual develoment speed is measured
and the next iteration is adjusted so that it does not contain more stories
than the developers can implement.
As you can see, for every step there is feedback. If there is no feedback,
the process is useless.
Regards,
Guillermo Schwarz.
David B Lightstone
"Guillermo Schwarz" <guillerm...@hotmail.com> wrote in message
news:3e424f70$1...@news.totallyobjects.com...
>
> "David B Lightstone" <david.lightst...@prodigy.net> escribió en
el
> mensaje news:x780a.1676$kT4...@newssvr19.news.prodigy.com...
> >
> > >
> > > That doesn't match what I have seen. If we apply the *principles* I
> > > mentioned above, what we find is that *everyone* is responsible for
> > > reporting process problems when they find them, and then the process
> > > gets fixed to eliminate the problem.
to bad someone snipped away the context. You will have to read back to
understand the issue
> >
> > The statement has much better impact when you realize that there is an
> > obligation to immediately fix the reported problem!
>
> Do you mean that the problem is not even evaluated first to see if the
> search for the solution is economically sound?
>
> Do you mean the design of the solution (the new process) is not evaluated
> first before implementing it?
>
> I bet both answers are "No". There is always evaluation, but how much?
Seems to me that you have just contradicted the claim
> > >If we apply the *principles* I
> > > mentioned above, what we find is that *everyone* is responsible for
> > > reporting process problems when they find them, and then the process
> > > gets fixed to eliminate the problem.
You probably should go back to the post where the "principles" are
articulated to understand the erroneous nature of either your beliefs, or
the principles. (do report your conclusion to the author of those
"principles")
> If
> the new process is slower and doesn't achieve more quality, we can always
go
> back to to the old process, can we?
One must recall where this approach is used in order to use it.
Kaizen, as applied in a factory, means - when the worked pulls the stop the
assembly line cord. The assembly line is stopped - No ifs, no ands, no buts
about it. No production, $1K per hour lost earnings. The evaluation
continues until the problem is fixed or declared a false alarm!
The "there is alway evaluation, but how much?" question is not applicable.
There are no tradeoffs to consider
My opinion is that the principles are unrealistic, because, as you clearly
indicate, they will not be followed.
When it comes to reports of process failure of XP, by definition they are
false alarms
Guillermo Schwarz
"Phlip" <phli...@yahoo.com> escribió en el mensaje
news:63604d2.03020...@posting.google.com...
> "Frank Andreas de Groot" wrote:
>
> > What makes you think that in my particular application I can "surely"
pass one bit
> > through my encoder/decoder? In order to "pass one bit", I have to write
both the decoder and decoder first.
> > And it works not by single bits. Your theories do not apply to my
practice.
>
> You are so smart that you are capable of writing the kinds of programs
> that you are not smart enough to write incrementally.
>
> Glad I ain't that smart.
That sounds sacarstic. I think the problem is not about writing it
incrementally, but being able to specify the tests that are necessary to
pass in order to be sure that the algorithm works. usually that can be done
in 10% of the time.
If the problem is that you want to compress the data very fast, you need
performance tests also. Then you can see in almost real time if any change
to the program actually achieves anything.
>
> > User interfaces are elementary.
>
> Right. And I can do the elementary kind, too.
>
> If a UI is so simple, does the interior of your encoder/decoder have
> one too? Can it illustrate the activities of the dataflow in
> real-time? (This topic is "software visualization", programs that
> display the activities of algorithms inside programs.)
>
> If your program's algorithm has no UI, how easily do you think you
> could add one? Could you drag an "encoder control" off a tool bar and
> drop it on a window, and then just wire it up? Could this control send
> commands back into the algorithm? How long before this simple code
> breaks? How would you know it broke?
>
> Remainder snipped unread.
Very good point, but I think this programmer never writes program that do
not compile or that do not behave as expected. He just wants the program to
work faster.
Kent Tong
> This "test first" idea is fine when you are doing database stuff.
> But it doesn't apply to hardcode coding.
> Example: I am working on quite a complex encoder. In order to test it, I need a decoder.
> But the decoder simply is the same as the encoder, only the data goes "backwards" :o)
> When the decoder works, so does the encoder. So when I have written my test,
> I have written my program. I can't write a test before I have written a correct program, otherwise
> my test would be wrong.
How do you actually test your encoder is working? I suspect
that decoding it using the decoder and getting back the
original input is not enough. For example, the following
trivial integer encoder and decoder would pass the test:
int encode(int x) {
return x+1;
}
int decode(int x) {
return x-1;
}
Therefore, you must have a much better way to test your
encoder. How? Are you using the (input, output) pairs
known to correct (eg, generated by the same algorithm
already implemented in another language)? Or do you
manually inspect the output for a certain properties?
Or do you just inspect the code and not do any other
kind of testing?
Phlip
> "Phlip" escribi:
>> "Frank Andreas de Groot" wrote:
>>
>> > What makes you think that in my particular application I can "surely"
> pass one bit
>> > through my encoder/decoder? In order to "pass one bit", I have to write
> both the decoder and decoder first.
>> > And it works not by single bits. Your theories do not apply to my
> practice.
>>
>> You are so smart that you are capable of writing the kinds of programs
>> that you are not smart enough to write incrementally.
>>
>> Glad I ain't that smart.
>
> That sounds sacarstic.
Sorry; I was just picking up the existing vibe...
> I think the problem is not about writing it
> incrementally, but being able to specify the tests that are necessary to
> pass in order to be sure that the algorithm works. usually that can be
> done in 10% of the time.
Get ready for an XP aphorism here:
The tests don't have to verify the algorithm. They have to verify the code.
If the first tick of an LZH compressor turns 'A' into 01101100, test that.
Nothing got compressed yet. Then test the next tick. Walk the algorithm
until the last tick. Then test that something got compressed.
> If the problem is that you want to compress the data very fast, you need
> performance tests also. Then you can see in almost real time if any change
> to the program actually achieves anything.
Now the aphorism switches to...
- pick an algorithm
- make it work
- make it right
- make it fast
- make it small
However, in terms of >picking< the algorithm, de Groot may indeed have
started out where there are none. That's not Software Engineering it's
Computer Science.
After the algorithm exists, re-write it using the above rules (and possibly
indeed TDD plus Pairing). Then it's clearer, more robust, and more
flexible. Rewrites are always good.
> Very good point, but I think this programmer never writes program that do
> not compile or that do not behave as expected. He just wants the program
> to work faster.
In theory, programs should also communicate to other programmers. Executable
encryption, to hide an algorithm, is another topic.
--
Phlip
http://www.greencheese.org/LucidScheming
-- It's a small Web, after all... --
Kent Beck
"Frank Andreas de Groot" <nos...@nospam.org> wrote in message
news:3Q10a.19190$CG6.3...@news4.e.nsc.no...
> This "test first" idea is fine when you are doing database stuff.
> But it doesn't apply to hardcode coding.
> Example: I am working on quite a complex encoder. In order to test it, I
need a decoder.
> But the decoder simply is the same as the encoder, only the data goes
"backwards" :o)
> When the decoder works, so does the encoder. So when I have written my
test,
> I have written my program. I can't write a test before I have written a
correct program, otherwise
> my test would be wrong.
The functional test for a data compressor might look like:
original= "The original string"
encoded= En.code(original)
assert(encoded.size / original.size < 0.6) // At least 60% compression
decoded= De.code(encoded)
assertEquals(original, decoded)
You can certainly write this in advance of any implementation of the classes
En and De.
You could also write unit tests for the decoder, one at a time, TDD-style.
Say we're doing run-length encoding.
encoded= En.code("AAB")
assertEquals([2, 65, 1, 66], encoded)
A hundred baby steps like this and you have clean code that works. You could
certainly choose not to work this way, but please don't tell me it's
impossible.
Kent
Jeff Grigg
implementation of a function to be trivially simple. For encoding strings,
for example, my first test might be to encode and decode an empty (zero
length) string:
x = encode("");
y = decode(x);
assertEquals("", y);
Implementation?
How about this:
EncodedDataType encode(String s) { return null; }
String decode(EncodedDataType e) { return ""; }
What? You don't like that implementation?
That's OK, we just need more tests to force us to implement a more
appropriate implementation. But this is a perfectly valid place to start.
Our next test might be to encode a one-letter string. Say, "A". Maybe this
shouldn't compress. Maybe we won't actually do compression until we test
"AAA". At that point I'd probably test the encoded data to ensure that it
was exactly what I expected. With artificially controlled inputs, we should
be able to predict exactly what our compresser will produce.
_ _ _
Another thought is that if the encoded format is standard, you could use
another vendor's tool to encode data, and then test to ensure that you can
decode it. Also, use your tool to encode data, and decode it with their
tool, to test that you encoded it properly.
> "Frank Andreas de Groot" <nos...@nospam.org> wrote in message
news:<3Q10a.19190$CG6.3...@news4.e.nsc.no>...
> > This "test first" idea is fine when you are doing database stuff.
> > But it doesn't apply to hardcode coding.
> > Example: I am working on quite a complex encoder. In order to test it, I
need a decoder.
> > But the decoder simply is the same as the encoder, only the data goes
"backwards" :o)
> > When the decoder works, so does the encoder. So when I have written my
test,
> > I have written my program. I can't write a test before I have written a
correct program, otherwise
> > my test would be wrong.
"Kent Tong" <ke...@cpttm.org.mo> wrote in message
news:c93e5fda.03020...@posting.google.com...
David B Lightstone
"Jeff Grigg" <jgr...@mo.net> wrote in message
news:v48v7c2...@corp.supernews.com...
> It's normal, when doing Test Driven Development, for the first
> implementation of a function to be trivially simple. For encoding
strings,
> for example, my first test might be to encode and decode an empty (zero
> length) string:
>
> x = encode("");
> y = decode(x);
> assertEquals("", y);
>
> Implementation?
> How about this:
>
> EncodedDataType encode(String s) { return null; }
> String decode(EncodedDataType e) { return ""; }
>
> What? You don't like that implementation?
> That's OK, we just need more tests to force us to implement a more
> appropriate implementation. But this is a perfectly valid place to
start.
Assuming there will never be more than one implementation of the encoder
and decoder, you are of course correct.
Now lets assume that there will be only 1 implementation, but the the
algorithm is actually a classified cypher. Any chance that the presence of
an error in the encoder, canceled by an error in the decoder, might make
the implementaion breakable but say an foreign government. You just
compromised national security, congradulations!
I trust you normally don't test your programs that way, and you realized
that you were swagging it.
Isn't test first development just great, or to paraphrase, the XP experts,
all (the method's) problems are implemention problems
As a side bar - Beck's approach would have worked. You actually have to
manually develop test cases.
>
> Our next test might be to encode a one-letter string. Say, "A". Maybe
this
> shouldn't compress. Maybe we won't actually do compression until we test
> "AAA". At that point I'd probably test the encoded data to ensure that
it
> was exactly what I expected. With artificially controlled inputs, we
should
> be able to predict exactly what our compresser will produce.
> _ _ _
>
> Another thought is that if the encoded format is standard, you could use
> another vendor's tool to encode data, and then test to ensure that you
can
> decode it. Also, use your tool to encode data, and decode it with their
> tool, to test that you encoded it properly.
A priori assuming the existance of an implementaion, is unacceptable
What if there are competative reasons for not swapping (first to the market
gets the money)?
John McClenny
TROLL ALERT!
Can't you people keep from swallowing the hook?
"Me so smart NO ONE can possibly understand my code! ( or stand to work
with me..."
In article <3Q10a.19190$CG6.3...@news4.e.nsc.no>, nos...@nospam.org
says...
> This "test first" idea is fine when you are doing database stuff.
> But it doesn't apply to hardcode coding.
> Example: I am working on quite a complex encoder. In order to test it, I need a decoder.
> But the decoder simply is the same as the encoder, only the data goes "backwards" :o)
> When the decoder works, so does the encoder. So when I have written my test,
> I have written my program. I can't write a test before I have written a correct program, otherwise
> my test would be wrong.
>
> Most of XP is good for newbie database programmers, only some applies to real programming.
> (You know, the kind of programming with 4-dimensional arrays ;o).
>
> There is not a soul who can even UNDERSTAND what I'm doing here, because the program does not merely involve
> high-tech coding, it also involves some unusual and complex IDEAS that need to be expressed in code,
> but a code buddy would have to be able to understand the IDEAS first behind the code.
> I'm writing AI history, and where do I find a "code buddy" who will look over my shoulder and tell me
> what I'm doing wrong? I have tried one to use a "code buddy". I had written an anti-alias routine
> that was obviously so complex that the people in the BASM n.g. didn't even understand it.
> (you can look up the source on Google)
> Some told me it couldn't work, others told me it was slower than some alternatives, etc.
> Code buddies are useles in some cases, as are "test first" scenarios.
> Even if I had 5 Peter Below's, it wouldn't help me in my really hard cases, honestly.
>
> I would prefer a good Thai double soap-sandwich massage to a code buddy any time.
>
>
>
b
John Roth
"John McClenny" <spa...@bebu.com> wrote in message
news:MPG.18b47caec...@news.supernews.com...
>
> TROLL ALERT!
>
> Can't you people keep from swallowing the hook?
>
> "Me so smart NO ONE can possibly understand my code! ( or stand to
work
> with me..."
I'm not so sure he's a troll. Other than that, I don't see much point
with discussing things with an opinion that seems to be set in
ferro-concrete.
John Roth
Phlip
> I'm not so sure he's a troll. Other than that, I don't see much point
> with discussing things with an opinion that seems to be set in
> ferro-concrete.
Beeeeeeeecause it feels SO GOOD when you STOP!
--
Phlip
http://www.greencheese.org/MakeItSo
-- Shock Value Added --
Guillermo Schwarz
> Guillermo Schwarz wrote:
>
> > "Phlip" escribi:
>
> >
> > That sounds sacarstic.
>
> Sorry; I was just picking up the existing vibe...
:)
>
> > I think the problem is not about writing it
> > incrementally, but being able to specify the tests that are necessary to
> > pass in order to be sure that the algorithm works. usually that can be
> > done in 10% of the time.
>
> Get ready for an XP aphorism here:
>
> The tests don't have to verify the algorithm. They have to verify the
code.
The code is just text. You can verify several things on text:
1. Syntactically correct. This can be verified by the compiler.
2. Code conventional. This can be verified by another automated tool, I use
an AWK script and JLint.
3. Semantically correct. The meaning of the method and the class can't be
verified by the compiler alone. You need to run a suite of tests to verify
that for correct inputs, correct outputs are obtained. Also for incorrect
inputs, the correct error conditions are signaled.
*Semantically correct* means algorithm verification.
>
> If the first tick of an LZH compressor turns 'A' into 01101100, test that.
> Nothing got compressed yet. Then test the next tick. Walk the algorithm
> until the last tick. Then test that something got compressed.
Ok, I don't what you think an algorithm is, but let me guess a definition:
An algorithm is a procedure that can be executed by a computer so that for
any given input, it produces an output and stops in a finite length of time
(or finite number of steps). Creating a thread is not an algorithm then, but
translating A into 01101100 is.
>
> > If the problem is that you want to compress the data very fast, you need
> > performance tests also. Then you can see in almost real time if any
change
> > to the program actually achieves anything.
>
> Now the aphorism switches to...
>
> - pick an algorithm
> - make it work
> - make it right
> - make it fast
> - make it small
I thought the aphorism stopped at "make it fast". What does *make it small*
mean?
>
> However, in terms of >picking< the algorithm, de Groot may indeed have
> started out where there are none. That's not Software Engineering it's
> Computer Science.
>
> After the algorithm exists, re-write it using the above rules (and
possibly
> indeed TDD plus Pairing). Then it's clearer, more robust, and more
> flexible. Rewrites are always good.
Always?
Guillermo Schwarz
"David B Lightstone" <david.lightst...@prodigy.net> escribió en el
mensaje news:UBr0a.3230$eb3...@newssvr19.news.prodigy.com...
>
> "Mike Stockdale" <MikeStock...@syterra.com> wrote in message
> news:IQf0a.85291$c41.2...@news2.telusplanet.net...
> > Frank Andreas de Groot wrote:
> > >>I wouldn't want someone with that attitude working for me.
> > >>--
> > >>C. Keith Ray
> > >
> > >
> > >
> > >
> > > I would not want to work for someone like you either.
> > > And as a matter of fact, I do not work for anyone.
>
> It is a statement that C Keith Ray would not be a suitable manager. This
> partly do to the nature of the application, but I suspect mostly because
he
> lacks the skills of a manager. Why he is attempting to create an
> environment of fear (as a mechanism to influence workplace behavior) is
> beyond me.
Maybe he thinks that people do their best job when motivated by fear. If
they fail, they are fired. If they do not do as told, they are fired. If the
boss doesn't like them, they are fired. There are so many reasons to be
fired, they are willing to do anything so that the boss doesn't fire them.
The manager asks for the impossible, so that middle managers and programmers
never become competent at anything. Salary raises are non-existant, except
for the ones who are willing to leave the company. It is a very good
strategy in the short term. In the long term the result is that programmers
never learn to program, they just learn how to hide their mistakes. Managers
never learn to manage, they just learn how to hide their mistakes. Everybody
works mandatory overtime, but still the application is full of problems and
everybody is willing to transfer the blame on someone or something else.
Then fear becomes a real problem, because the deadline was several months
ago and there is no way to make the application work.
David B Lightstone
Many months ago there was a tirade of "bad worker" discussionss. Can't
imagine for my life the kind of organization that produces "bad workers"
:-) or more importantly the kind of organization which would create an
environment where people might erroneously (and deliberately) be call "bad
workers"
Phlip
> The code is just text. You can verify several things on text:
> 1. Syntactically correct. This can be verified by the compiler.
> 2. Code conventional. This can be verified by another automated tool, I use
> an AWK script and JLint.
> 3. Semantically correct. The meaning of the method and the class can't be
> verified by the compiler alone. You need to run a suite of tests to verify
> that for correct inputs, correct outputs are obtained. Also for incorrect
> inputs, the correct error conditions are signaled.
>
> *Semantically correct* means algorithm verification.
TDD tests, out of the box, don't test all those things. They just make
refactors safer.
> An algorithm is a procedure that can be executed by a computer so that for
> any given input, it produces an output and stops in a finite length of time
> (or finite number of steps). Creating a thread is not an algorithm then, but
> translating A into 01101100 is.
Developing a new algorithm is computer science. Adding one to a
program is software engineering. XP only decrees how to do the latter.
> > - pick an algorithm
> > - make it work
> > - make it right
> > - make it fast
> > - make it small
>
> I thought the aphorism stopped at "make it fast". What does *make it small*
> mean?
Small footprint.
Observe these are indeed phase - going from "make it small" back to
"pick an algorithm" or "make it work" would break "make it small" in
ways hard to recover from.
> > After the algorithm exists, re-write it using the above rules (and
> possibly
> > indeed TDD plus Pairing). Then it's clearer, more robust, and more
> > flexible. Rewrites are always good.
>
> Always?
XP doesn't get dishes virtually spotless. XP gets dishes spotless.
Otis Bricker
I don't think there was anything in the original post by Mr Ray that
even remotely points to his suggesting the use of fear as a management
tool. In fact, I cannot imagine how David could have read any such
view into it.
Mr. Ray was stating that he would not want someone with the attitude
expressed in this statement, "And why on earth should I teach someone
my trade secrets and let them sit next to me and interfere with my
work?" working for him.
Seems like a reasonable view to me. Such a person is not working for
you. He is using you to get a paycheck. You may need someone working
for you who happens to have no interest in sharing skills or
knowledge. You may need someone who views all his coworkers as
inferiors who need not be tolerated. You may need them because they
provide some rare talent you cannot do without.
But I would much rather hire and work with people who like to work
together as a team. Who try to support each other and share knowledge
and experience. Who see coworkers as valued resources rather than
skill sucking parasites.
But I like to be happy. Maybe others don't.
Otis B
David B Lightstone
"Otis Bricker" <obri...@my-dejanews.com> wrote in message
news:7dbbbefe.03021...@posting.google.com...
Fortunately I can.
>
> Mr. Ray was stating that he would not want someone with the attitude
> expressed in this statement, "And why on earth should I teach someone
> my trade secrets and let them sit next to me and interfere with my
> work?" working for him.
Perhaps it is best to let Mr Ray speak for himself, rather than trying to
second guess him
>
> Seems like a reasonable view to me. Such a person is not working for
> you. He is using you to get a paycheck.
Don't wish to be argumentative here, but with a position comes
responsibilities and obligations. In exchange there is a paycheck. We all
are always using others to get a paycheck.
> You may need someone working
> for you who happens to have no interest in sharing skills or
> knowledge. You may need someone who views all his coworkers as
> inferiors who need not be tolerated. You may need them because they
> provide some rare talent you cannot do without.
>
> But I would much rather hire and work with people who like to work
> together as a team. Who try to support each other and share knowledge
> and experience. Who see coworkers as valued resources rather than
> skill sucking parasites.
I understand you wish to impose via peer pressure those obligations, but
frankly this is a capitalist society and knowledge is both a source of
power and income. If the terms of employment are such that the prevalent
ethic, great, but I suspect that this is not the case. As a point of
amusement, consider the last job negociation which you had. My most recient
one started with a single question - What are your salary requirements? I
immediately ended the interview. I have not interest in explaining why.
I would like to see intellectual property eliminated also, but don't expect
it to occur during my lifetime
Keith Ray
obri...@my-dejanews.com (Otis Bricker) wrote:
[...]
> I don't think there was anything in the original post by Mr Ray that
> even remotely points to his suggesting the use of fear as a management
> tool. In fact, I cannot imagine how David could have read any such
> view into it.
>
> Mr. Ray was stating that he would not want someone with the attitude
> expressed in this statement, "And why on earth should I teach someone
> my trade secrets and let them sit next to me and interfere with my
> work?" working for him.
>
> Seems like a reasonable view to me. Such a person is not working for
> you. He is using you to get a paycheck. You may need someone working
> for you who happens to have no interest in sharing skills or
> knowledge. You may need someone who views all his coworkers as
> inferiors who need not be tolerated. You may need them because they
> provide some rare talent you cannot do without.
>
> But I would much rather hire and work with people who like to work
> together as a team. Who try to support each other and share knowledge
> and experience. Who see coworkers as valued resources rather than
> skill sucking parasites.
>
> But I like to be happy. Maybe others don't.
>
> Otis B
Thanks, Otis. You got what I meant.
--
C. Keith Ray
Peter Kootsookos
"Phlip" <phli...@yahoo.com> wrote
> John Roth wrote:
>
> > I'm not so sure he's a troll. Other than that, I don't see much point
> > with discussing things with an opinion that seems to be set in
> > ferro-concrete.
>
> Beeeeeeeecause it feels SO GOOD when you STOP!
>
Ah, the old beating your head against a brick wall argument....
Ciao,
Peter K.