
Extreme Programming, a Reflection - joseph_cooney
http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html
======
barrkel
The things that I remember XP being _controversial_ for were pair programming
and TDD - real TDD, where you write the tests first and let the tests drive
the design. And those are the two things that I don't really see as having
caught on.

I mean, pairing is a fine approach when training someone up on a codebase, but
it tends to be much more effortful for the guy in the driving seat, while the
guy looking over your shoulder is making small comments and doing researchy
lookups. This makes it less than efficient when both people are at the same
knowledge level. The extra eyes looking for bugs is debatable; the bugs are
more thoroughly found with tests.

Test-first TDD is even less popular. Norvig vs Jeffries was enlightening -
[http://devgrind.com/2007/04/25/how-to-not-solve-a-
sudoku/](http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/) .

Software does have a much heavier focus on testing than it used to, to the
point that in many projects, everything is implemented twice - all features
have two representations, one in the form of the implementation, another in
the form of tests, and often with the lines of test code outnumbering the
implementation.

But other things have suffered IMHO; making code easy to test tends to over-
abstract it, making it more parameterized and exposing more implementation
details of high-level abstractions.

APIs are often uglier with a lot more exposed symbols to handle the
parameterization, with various bits and bobs asking for interfaces that only
have one concrete implementation that can only be created by a factory, and
you have to learn the knack of actually instantiating the useful bits anew for
each library. I've got Java squarely in mind, of course, and I'm convinced
better language design can solve the problem with less harm to the software.

~~~
sgt
Regarding pair programming, I also see it as paying the salaries for 2x
developers, yet gaining very little from it. Productivity may be even less
than from a single programmer, at least in my experience.

To elaborate, I've tried pair programming myself and it was completely
inefficient when we tried it. I'm not going to dismiss it entirely though,
perhaps we approached it the wrong way. Personally I just need a bit of space
before I can start focusing in-depth about certain problems.

This is also why I like to be well-prepared before attending team design
decisions, because coming up with good ideas "right there and then" is
difficult for me.

~~~
JackMorgan
I think of pair programming like dancing. How much practice does it take to be
able to dance with a partner before it's natural? More than a week, that's for
sure.

I pair on all production code at work with only two other guys. I've worked
with them for the last year. Together, any combination of the three of us is
easily twice as effective as the fastest in our team. Something about the
rhythm of the session, alternating roles, support when tackling boring parts,
and the camaraderie frees us up to just get stuff done.

But, we work in a very complex domain that, a year in and many seminars by
product later, we only barely are starting to grasp, with a large difficult to
grasp system, sometimes solving problems just outside our comfort zone. It's
not just CRUD and forms. So, maybe pairing is the four wheel drive of the
programming world: uses more gas on the highway, but depending on your
terrain, it might be the most fuel efficient way to get across a mountain.

------
grimer
In regards to pair programming - I realized recently that I'm opposed to it
just because I don't enjoy it. I don't like having someone look over your
shoulder while programming, or looking over someone else's shoulder while they
are programming. It is exhausting. Collaborating in front of a whiteboard for
a few hours is fine - I just don't want to do it all day. I also don't like
feeling guilty taking a 5 minute break to read hacker news, or my personal
email.

And I'm in the programming industry because I enjoy programming, so would want
to work in an environment which I enjoy - and in today's market, i have the
luxury of picking my employer.

I'm sure not everyone feels the same way, but I suspect I'm not alone in that
opinion.

~~~
philbo
You looking over someone's shoulder or them looking over yours is definitely
not pair programming though. It is exhausting though, I agree with that part.

------
pistacchioso
Putting my headphones in, drifting in my own, private world of code is to me
one of the simple pleasures of life. Ok with short meetings and thight, small
schedules and the like, but put someone watching at my screen while I'm coding
and I can easily commit an homicide.

~~~
lmm
I don't enjoy pair-programming. I avoid it as much as I can get away with. But
looking at the results, it's an inescapable fact that I produce higher-quality
code when I do - so for those critical pieces that _need_ to be bug-free, I
force myself to do it.

~~~
berntb
Is that personal experience or a general research result?

Is the result better than with careful code reviews [of the critical pieces]
(both after writing, but also short checks during development over a code
listing and coffee)?

Intuitively, everything with coffee involved ought to be better! :-)

~~~
lmm
Just personal experience.

Better than some theoretically perfect practice of careful code reviews? I
don't know. Better than code reviews as actually implemented everywhere I've
worked? Yes. (In particular I find it's really hard to maintain the discipline
of carefully going through each other's code when you know that most of the
time you won't find anything)

------
henrik_w
The XP book was hugely important for me. I read Kent Beck's article on Extreme
Programming in IEEE Software in October 1999, and got the book as soon as it
came out. For the first time I saw a methodology that reflected how I actually
liked to work. I hadn't done pair-programming then, but working in small
increments, with lots of tests, rewriting etc - more agile in short.
Previously, I wrote programs _despite_ the methodology (like RUP, or company
internal methodologies), but here was a system that actually helped. Truly
revolutionary at the time.

~~~
ollysb
The strange thing is that this is how everyone begins to program you write a
little code and get something working. Then you add a little more, reorganise
things a little and keep going. It's a natural process that somehow gets
trained out of us in CS courses. We're taught how to plan a whole system and
them build it. Long running projects interacting with an infathomonable number
of users put paid to that though. I think the thing extreme programming got
most right is that software is about people. Telling the computer what to do
is the easy bit. Figuring out what the users want them to do is the hard part.

~~~
discreteevent
The main thing for me is that its virtually impossible to build a complex
system (essentially complex that is) without having good feedback and then
adjusting the design to fit. That feedback comes from testing, review and the
customer. The shorter the feedback cycle the quicker you settle on the target.
The XP book helped spur this on in an age where a lot of people had lost the
run of themselves. However these ideas were around and practiced since
software development started:

[http://www.craiglarman.com/wiki/downloads/misc/history-of-
it...](http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-
larman-and-basili-ieee-computer.pdf)

And before that for other activities: "Plans are nothing; planning is
everything." \- Dwight D. Eisenhower

------
inglor
Another post saying nothing by uncle Bob. His ability to say nothing never
ceases to amaze me -_-.

He's one of the good guys, that's for sure - but every time I read his blog I
keep waiting for that something new and it never comes.

------
thebear
In the short section entitled "Success" toward the end of the article, the
author repeats the sentence "Extreme Programming succeeded" five times,
slightly rephrased each time. To be perfectly honest, I find it hard to
comment on this without sounding derisive. There is no hint at what
"succeeding" even means for a software methodology, and even if we assume we
know what "succeeding" means in this context, there is not a shred of evidence
for the truth of the statement. A poorly defined statement repeated five times
without evidence or proof.

------
lifeisstillgood
It's still relevant - I doubt that 2% of teams do all 12 (mostly it's the pair
programming) but it is without a doubt the seminal work on software in
business of the last 15 years.

~~~
pjmlp
In the enterprise world I move on, it is mostly a checklist to say a project
is agile.

Many companies are still run waterfall like, or without any kind of process.

When we bring in agile methodologies into the project, it starts slowly, but
eventually everything is in place and everyone is doing it in an agile way
(XP, SCRUM, whatever).

When the first project escalation arrives, or the deadlines are not possible
to be achieved, the developers start slowly going back to the original way of
working.

In the end you get mini-waterfall projects with a sprint duration, but the
management puts agile on the project bullet points.

~~~
lifeisstillgood
I know the feeling - and my view is a bit brutal - but it's down to tools and
people.

For most enterprises _automated build, test, deploy_ (ie CI/CD) is the one
missing tool and one absolutely necessary tool to capture and keep benefits of
agile - it's capital.

And also for most enterprises you could lose 1/3 of the IT staff without
noticing.

~~~
henrik_w
As edw519 tweeted:

(Great Process + Average People) < (Average Process + Great People)

------
khaledh
[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

------
FrankenPC
I love pair programming. Frankly though, it takes several hours of committed
time to be really useful. It's hard to get two production programmers to sit
down together for a few hours to focus on this. To get around the time hurdle,
I've proven to upper mgmt that the amount of bug fixes or efficiency
improvements is easily greater than the amount of product the two alone could
have achieved. There's a Tesla-ish resonance that occurs when two people are
focusing on the exact same problem. LOVE IT.

------
ColinDabritz
The Ten Year Agile Retrospective: [http://msdn.microsoft.com/en-
us/library/hh350860(v=vs.100).a...](http://msdn.microsoft.com/en-
us/library/hh350860\(v=vs.100\).aspx)

From June 2011, this article covers four key success factors for the next 10
years of agile. Great thinking on software development.

------
steven2012
I was developing software back then when extreme programming came about. It
wasn't controversial at all. In fact, everyone I knew thought it was a much
better way of programming than the current waterfall method. The only problem
was inertia from management, which is always the case.

------
city41
I like a lot of what XP brought to the table, except pair programming. I find
it's genuinely not effective most of the time. It _is_ very effective when
teaching someone. But in general I have found it to be slower, produce worse
code, reduce accountability, and causes frustration. I'm currently working on
a long blog post detailing my thoughts on it.

~~~
dack
I'm interested in seeing your blog post - subscribed in anticipation! I
definitely agree with the slower bit, but my experience has showed that
paired-on code is generally higher quality as the engineers discuss what
really should be done and the semantics of what's being built.

There are definitely tasks in which I would avoid pairing - specifically those
that are either very ill-defined (like a spike or bug hunt) or too easy (write
some data transformations). However, the tasks that should result in a clean,
well tested API with edge cases taken care of, tend to be higher quality while
pairing in my experience.

------
asdasf
I was pretty shocked to see a programmer that delusional about XP and its
influence. Then I got to the bottom and saw it was an XP snake-oil salesman
writing it, not a programmer. Surprise. All 12 of those things predate XP, and
most of the 12 things are situational. There is virtually never a case where
following all 12 of those things makes sense. But that is exactly what XP was.
It demanded you do all 12. Just saying "because some people still do some
things in that list, XP mattered" when those things were being done before XP
came out is absurd. "Which ones don't you do?", all of them but avoiding
overtiming.

