

Programming like Kent Beck - simenfur
http://blog.iterate.no/2012/06/20/programming-like-kent-beck/

======
discreteevent
Its refreshing to see that he focuses on integration testing. Most programmers
I know understand that in any kind of engineering every decision is a
tradeoff. So testing every line of code means you are trading off speed and
flexibility for very little gain in some cases (80/20?). XP introduced the
idea that there isn't a tradeoff. You take things to the extreme. So as a
methodology its not a good one to follow. But as a _force_ it was absolutely
beneficial. There were plenty of moderates arguing against the whole waterfall
thing for years and getting nowhere. XP recognised (conciously or not, I don't
know) that the zealots who enforced waterfall weren't the brighest so there
was no point in putting subtle arguments to them. They would only move to
something that was a bit boneheaded. And so XP as a force actually managed to
move a lot of the industry more twoards the centre.

~~~
route66
<http://leanpub.com/leprechauns>

In the downloadable sample there is a nice analysis which refutes the "zealots
who enforced weren't the brightest".

In the short: there were no zealots. Nothing was enforced, the term
"waterfall" comes up much later and it was meant as being iterative from the
beginning.

So one might ask: how come that this folklore is being trumpeted all around
like a truth?

~~~
discreteevent
I know that waterfall was originally meant to be iterative. What I meant by
"the whole waterfall thing" was the practice of it in industry. And by
"zealots who enforced weren't the brightest", I meant mainly management in
enterprise development who arent' bright enough to understand what development
is and so want to treat it as a repeatable process like manufacturing which is
much easier to 'manage' than any kind of creative process.

------
andrewcooke
wasn't beck the person who couldn't solve some basic problem recently? it was
mentioned here. [google...] ok, here it is - re-formatting some text (in a
very basic way - just clipping lines) - [http://blog.8thlight.com/uncle-
bob/2012/04/20/Why-Is-Estimat...](http://blog.8thlight.com/uncle-
bob/2012/04/20/Why-Is-Estimating-So-Hard.html) the hn discussion is at
<http://news.ycombinator.com/item?id=3880522>

(not sure what my points is; the article here seems quite reasonable - very
good advice, in fact, imho. i guess it just stuck in my mind as being so odd.)

~~~
KentBeck
Yes, that was me. I get stuck sometimes. In this case the key insight is that
the recursive algorithm is much easier to get to work than the iterative one.
There was also the added complexity of two mammoth egos attempting to
collaborate.

~~~
andrewcooke
thank-you for removing the dissonance there (and i am so glad i added that
disclaimer ;o)

