> > Do you trust the judgement of all pairs on your team on
> > all pieces of the code? In my experience, no one
> person
> > knows all the code in a large app, and some people
> aren't
> > really qualified to play in certain areas. The reality
> of
> > large software systems is that there are certain areas
> > where complexity is mandatory - it can't be avoided, XP
> or
> > no XP.
>
> Agreed. But just because everyone can change any of the
> code all of time doesn't mean that people will dive into a
> part of the system they don't understand and change it. In
> our teams we've found that if you find you need to change
> something non-trivial in unfamiliar code you pair with
> someone who knows that bit of the system.
>

If it's a 6 or 7 figure project, do you really want to gamble on the judgement of individual programmers? Does self-organization really work when you have hundreds or thousands of user stories in the final product?

I personally believe in loose ownership. There should be definite "experts" in various areas of the code, but any developer should be allowed to make changes as needed. The difference from straight XP isn't so much physical as psychological. You know there's a guy that knows a particular sub-system inside and out, and that guy (or gal :-) is far less likely to screw up the more complex aspects of the code. The idea of letting developers sort it out and collectively own everything seems rather naive.

And this goes back to my original question that you've kind of avoided - are all pairs equal? Given a culture of anyone-can-change anything, what happens when you stick a new guy (maybe very skilled, but new nonetheless) on a hunk of code that's been refined over many months? I know in alot of cases the real expert in those areas isn't going to be very interested in pairing up with someone who's only going to slow him down. More extensive documentation would be a boon here in easy people in - but XP appears to frown on that, too (in fact, Martin, you seem to oppose even the idea of shaping semi-concrete interfaces and publishing their definitions out to the rest of the group).

> Of course this assumes that your developers are
> professional enough to have some sense of where to go or
> not go. If your team has developers that are poor enough
> to do reckless changes then you'll certainly need more
> controls. Then the right thing would be something like
> limiting commit privileges or a strict code ownership
> scheme.
>

Let's be candid here. We can't pick our colleagues, and alot of people who are only so-so came into the biz during the dot-com rush. To say otherwise is to gloss over a serious issue in the IT world. If you take this at face value, then your best bet is to get the most out of everyone on the team, and to hell with software ideologies. I may not be sanguine with the performance of some of my staff, but I can almost never do what XP suggests and just kick someone off the team. It's not in my control. And I can't have them sitting on their thumbs, or wrecking things that used to work fine. A way needs to be found to make everyone on a team productive within their capabilities. This is difficult in XP, where equality is promoted above almost everything else.

Pairs don't help here either. XP seems to ignore psychology - to its detriment. Some people just suck at pair programming - but are otherwise very good and very productive. I do not wish to kick someone off a team just because he doesn't work well in pairs. Likewise - while I believe in mentoring, I don't believe in saddling a senior person with a novice in the name of collective code ownership. Risk, reward, and work all come into play here, and again is a part of psychology. Many senior developers will see pairing with an individual of lesser skills as a punishment - and they're sort of right.

What I want to see is XP to acknowledge that there is not one level of programmers - or two, or three, or fifty. People are truly individuals - and that's why collective ownership doesn't work on larger systems.

> But I think there is a significant amount of projects
> where the developers do (mostly) the right thing.
>

The number of qualifiers in the above statement is kind of telling, don't you think? Significant and mostly? I think XP needs to recognize that not all college grads will eventually turn into wizards, and that not all wizards are benevolent and kind old geezers who love to teach up and coming youngsters. Software is about people, and people are remarkably varied. The whole point of project managemen is to work with the people you've got to make a system work.

>
> > >
> > > So make it automated. Use Continuous Integration
> > >
> >
> <http://martinfowler.com/articles/continuousIntegration.htm
>
> >
> > > > and a tool like Cruise Control
> > > <http://cruisecontrol.sourceforge.net/>
> > >
> >
> > This is nice for functional tests, but increasingly
> > today's systems are highly interconnected and include a
> > large number of non-functional tests. For example -
> your
> > unit test for an order management module isn't worth
> much
> > if it doesn't exactly mimic the input/output of a 3rd
> > party system you must interact with. To truly test
> this
> > module you may very well need to interact with this
> third
> > party system, and this can be very time consuming.
>
> In those cases I advocate writing a stub for the third
> party system. Certainly writing the stub is some effort,
> but it's usually less effort than people fear, and usually
> has higher payoffs than people realize.
>

I think you miss the point here - you're duplicating here. You have the real system, and something mimicking the real system. The problem is that it's extremely easy for the two to get out of sync. Just like duplicate code is bad, stubbing out a system indefinitely is just as bad and can lead to endless confusion. Following your advice, I can pass my unit tests with flying colors but still fail at integration/QA time - because my stub doesn't match reality.

Just like relying on unit tests as a front-line defense is bad, so is relying on stubs written by the same developer who wrote the stub. It's self-referential and not based on the realities of the whole system. No one cares if you work with your stub - only if it works with the real system. The stub is useful if you don't have a real system, but should be discarded at the earliest opportunity.

> Martin

-Mike

> > I'm forced to completely disagree. One given instance
> of
> > an explicit piece of code is easier to understand. "N"
> > instances of code 99% the same is not easier to
> understand
> > - even it's only three instances - because to
> understand
> > the whole mechanism you have to look at all the
> > instances.
> >
> That's true, but I don't think that's the kind of
> "explicitness" we are talking about. Perhaps you have
> three methods whose names each explicitly say what they
> do. That makes code calling them more explicit. But if
> those methods do 99% of the same thing, then they that 99%
> code should be factored out as one private helper method
> (also with an explicit name). Now it is a judgement call
> whether to collapse the three public methods into one
> public method with a parameter. The point of the
> explicitness argument I think is simply that part of the
> way you make that judgement is by asking yourself what
> appoach (three methods versus one) will make the client's
> code easiest to read and understand, and that method names
> that explicitly say what they do tend to improve
> readibility.
>

I concur completely in those areas. I think part of the mismatch is not based on the interview, but one of the supporting documents (Mr. Fowler's essay on explicitness). In that document the view is very much (and this is a paraphrase, not a direct quote) "do exactly what the user story says, do not extrapolate, and make it as concrete as possible". The last example given is the discount plan example, and I disagree most heartily with that example. There, the discussion is about a common business component (discount plans), of which there are several variations (in the example, three). In that sort of situation the explicit code is a cop out. You're making someone's life more difficult down the road on purpose so you can get this iteration in with minimal work. I think that's wrong - not morally, but in terms of overall work on a project. In short, the coder is just _asking_ for trouble by being explicit in that sort of situation.

> > Worse - you've still overlooked the cost and effort of
> > programmer time. Explicit solutions always need a
> > developer to make any sort of change. That's not only
> > inflexible, but expensive. In NYC, where I work,
> > developers routinely get 6 figures or just below. The
> > last person I want fiddling with a discount rate is a
> > programmer.
> >
> I wouldn't equate explicit with non-configurable. You can
> have a highly configurable system from the outside whose
> code on the inside is explicit. Explicit doesn't mean you
> don't use data. It just meanst that when I look at your
> code it kind of tells me what it does by the way you've
> partitioned things and named them.

I don't think that's so much as explicit as just plain well written. If you re-read Mr. Fowler's essay I think you'll see that he's directly arguing against data-driven code unless a powerful argument is made for it. Explicit there means very, very explicit, to the point of hard-coding your discount rate for the "blue plan" (or whatever) directly in your code at 15%. Perhaps the example was just a really bad one from my perspective, having seen precisely such code push projects past deadlines and over budget because someone took a very, very short term view of the requirements.

It's even worse in the XP sense. Given rotating pair programmers working on different stories at different times, the developer is in effect foisting the effort to make the code configurable on some other developer at a later time - when the system is more complex and by definition harder to refactor. See the essay by Mr. Fowler's company which dissects a large project which took the XP approach, and how following requirements literally at every stage got them in to trouble.

The problem I really have with this flavor of expclitness is the concept of religiously following the requirements of this iteration (possibly out of many, many iterations) and refusing to apply any forsight at all. Mr. Fowler can assert all he wants that it works out somehow in the end, but real case studies say precisely the opposite.

-Mike

> We've pretty much run this thread dry. Summing up I'd say
> that you are inclined to do data driven approaches much
> earlier than I am. Clearly also my choice of example hit a
> sore point - for which I apologize but defend myself by
> saying that any example simple enough to follow is going
> to be simplistic.
>

Reading your most recent interview, I'd say our approaches match somewhat, but differ mostly in timing. I, too, always start out with an explicit approach in the beginning. This helps me wrap my mind around the problem in full and really test out all the boundaries of the problem space. The difference is that I'll rarely release that code. It's my "fooling around code". Once I've gotten something working with the bailing wire and duct tape, I throw it all away and write a more appropriate solution from scratch. It's not so much refactoring as writing a proof of concept to figure things out, throwing 90% of that out, and then writing the real thing.

As you mentioned, this seems wasteful but in fact wonderfully concentrates the mind and figures out solutions to problems fast. But I think it's important not to release that conceptual code but something that benefits from what you learned. From what I've read, you seem comfortable releasing stuff into an iteration that has alot of "explicitness" in it, and leave it to a later time to refactor when more information becomes available. I've tried that approach, and it's burned me more times than I care to admit. Taking the time to look ahead just one or two iterations, and applying hard-won business knowledge from past projects, means make the code a bit more configurable up front to avoid several painful refactors down the road.

> There's also a difference of opinion on ease of
> refactoring into a data driven approach. I find it quite
> easy to write very concrete code and rapidly generalize it
> - to a data driven style if needed. You would prefer to
> start data driven from the beginning.
>

I think the difference is deeper than this. You have repeatedly stated that refactoring is an on-going process that never stops (yes, this is a paraphrase). I prefer to rapid prototype a proof, chuck it, re-write and then be satisified with the result until several iterations later when the well-docmented "pain factor" gets too high. In my own projects, constant refactorings are not practical because all the details of a given component or sub-system do not stay fresh in my mind indefinitely. Because of this, constant refactoring means I'm going to be re-structuring code that's a bit fuzzy to me - and I believe this is a bad thing. In short, I prefer to take costs up front. If I make a mistake doing that from time to time, fine. But most of the time that up-front work pays off down the road when crunch time comes and final deliverables loom.

In short - never, ever put the hard work off for last, because that's when you'll have the least amount of time to do it.

> Martin

-Mike