Fog Creek Software
Discussion Board

To interchange or not to interchange (programmers)

One of the practices of extreme programming is moving people around:

<XP>A team is much more flexible if everyone knows enough about every part of the system to work on it. Instead of having a few people overloaded with work while other team members have little to do, the whole team can be productive. Any number of developers can be assigned to the hottest part of the system. Flexible load balancing of this type is a manager's dream come true.</XP>

In contrast, Joel warns against doing this blindly:

<Joel>Programmers are not interchangeable. It takes seven times longer for John to fix Rita's bug than for Rita to fix Rita's bug. And if you try to put your UI programmer on a WinSock problem, she'll stall and waste a week getting up to speed on WinSock programming.</Joel>

Joel's comments make more sense to me, but I'd like to hear some real examples of the XP practice being used.  Has anyone tried it?  How does it affect code quality and productivity?

Thursday, September 4, 2003

One way of looking at it is that they're talking about two different things.

XP is advocating the renaissance programming method - at the most basic it's one person who designs the database, writes the SP's, biulds the business objects, and hooks up the website. You can expand this philosophy to a team where, instead of splitting the work in the traditional horizontal fashion (DBA, coders, webmasters), you divide it into functional stovepipes as much as possible (John does the personnel section, Frida does the images section). You also encourage them working together at interfaces.

In addition, if Frida finishes her image handler early, then she picks up some of John's work - testing the data entry screens, finishing up loose ends on the reporting, etc, etc.

The huge benefit here is that it's easier for people to find bugs because they know the whole system.

Joel, I think, is saying that you cannot think that you can put John on HNP (Hot New Project), stick Rita in his chair, and expect the schedule to remain unchanged. This is a corollary to Brooks' Law that adding people to a late project only makes it later - you cannot ignore the ramp-up time, esp. since it will be pervasive through all the work. In addition, John is now only 3/4 of an asset, because 1/4 of his time is answering Rita's questions about his work.

Joel's guideline doesn't invalidate the XP guideline - it's a consideration in implementation.


Thursday, September 4, 2003

Another thing to consider is what happens if John or Frida find other jobs, get fired for embezziling, get hit by a truck, etc.

Flamebait sr.
Thursday, September 4, 2003

I've been in this situation before. Moving people around brings a lot of benefits, when done properly.

First, there is major ramp up time. You don't take the guy who's spent the last year on EDI and expect that he's going to be an accounting guru in a week. But he can start picking up some loose ends and helping out.

Eventually what you get is a broader base of knowledge among all of your developers. This is a good thing, because it protects you in case a key programmer leaves. It also gives you greater capacity, since it reduces the risk of one or two programmers becoming a bottleneck. If there's massive accounting programming to be done, you now have a lot more people who can handle it.

An unintended benefit is that moving people around helps to prevent burnout and boredom.  Giving them something new to learn every now and then keeps the brain fresh, so they don't go find another job just to keep the brain from geting stale.  Speaking as somebody who has been burned out before, this is important.

Clay Dowling
Thursday, September 4, 2003

I think interchanging also ties in with Keeping it Simple. If a system is reasonably simple, then interchanging isn't a big deal. If it's complicated, then in the XP world,  successive programmers will refactor it until it *is* simple.

And when you have tests, then if the tests pass, by definition the changes are OK.

Like Pair Programming, it's a very different mindset, and one that frankly is alien to most places that I've worked.

Peter Breton
Thursday, September 4, 2003

Replacing Fred with George and expecting George to be as productive as Fred is a mistake.  This is what Joel was warning against.

However, having George sit *with* Fred for a while is a good plan.  There will be some lost productivity at first as George explains things to Fred, but eventually Fred will be able to contribute to that area of the project as well.

That's how I understand it anyhow.

Richard Ponton
Thursday, September 4, 2003

Here's an idea. Why don't we create a mindset among programmers that it would be good for them to make themselves interchangable?

We will be able to replace them anytime then, and thus reduce their bargaining power. (They don't teach them anything about business in their courses, do they?)

While we're at it, we could encourage the idea that it's noble for them to donate their work to business. Call it open source.

Goddam, no wonder I'm worth $10 million.

Thursday, September 4, 2003

As a manager (well, former manager.  Damn economy!), I can say that this is a very tough thing to balance.  Both sides are right.  I'd LOVE to have a team where everyone was equally competent at all parts of the job, assuming they were equally good and not crappy.

Practically, it's difficult, because like Joel said, it's often inefficient.  Also, you'll find people like different things and so what John likes, Mary hates and vice versa (although it's rarely mutally exclusive).

What worked well for me was code reviews.  I'd have the whole team review John's new code.  We'd help him by finding problems, teaching him tricks, etc. and at the same time everyone saw his code.  If John left or was hit by the proverbial beer truck, anyone could jump into his code pretty easily.

I can't help on the XP aspects as I've never done it.  Well, I've done many pieces of XP actually, but long before it had that name (but that's another topic).

Thursday, September 4, 2003

Philo wrote, "This is a corollary to Brooks' Law that adding people to a late project only makes it later - you cannot ignore the ramp-up time, esp. since it will be pervasive through all the work. "

Steve McConnell wrote an article titled Brooks' Law Repealed?

If anyone is interested you can read it here:


As Philo already mentioned, you are talking about two different things here.

Basically, Joel is talking about software projects that involve job stratification (i.e. a bunch of specialists) while the people who are promoting eXtreme Programming are telling you they have a different philosophy towards software development (i.e. programmer is involved throughout the lifecycle of a project). 

Personally, I think XP'rs are foolish to allow critics to compare their methodology to methodologies that promote specialization (i.e. big upfront design).

Imo, an agile methodology such as XP is perfect for organizations that don't currently use any type of methodology and:

* Can't afford to hire specialists
* Primarily do small-to-medium size software projects

One Programmer's Opinion
Friday, September 5, 2003

[Joel's comments make more sense to me]

Personally, I think Joel's full of what makes the grass grow green on this one.

Sure, you can't always avoid it, but allowing developers to "specialize" in areas of your project's application is never a good idea. It tends to lead to an insular, segmented team that can begin to act as if what happens in one area of the project has no bearing on the others. You also tend to get that defensiveness that crops up when one developer starts to feel pressure because there's a lot of work, or problems, in "their" area of the code.

It also severely limits your options if you are the project manager/tracker. If your specialist in one particular area steps in front of a bus, you're kind of S.O.L, aren't you? Or, to put it more delicately, what if they go on vacation and something pops up?

In my experience (2+ years doing XP on real projects), developers LIKE common code ownership. Developers are human too. They don't like being tied down to a particular piece of code any more than a mechanic would enjoy being told he could only fix tires. They know that if you do that sort of thing long enough, the next thing you know you're stuck in the basement of a bank's IT department maintaining Cobol legacy systems.

It's also my experience that, if you work to maintain common code ownership, it DOESN'T take any longer to fix bugs than if you had a specialist.

Joel's statement sounds to me like something someone would say if they inherited an environment with calcified private code ownership. Sometimes that happens and you have to deal with it. Only you can decide if rocking the boat and trying to move to collective code ownership is worthwhile. But if you have the choice at the outset, personally, I think you'd be a fool to let private code ownership get establish in your project.

Just my opinion.

Friday, September 5, 2003

I can't agree with David's comment about code reviews strongly enough. I'm the sort of person that likes to feel like he's got responsibility for a specific part of the system, for the following reasons:

1. During development, I can re-architect and fix bugs without stepping on anyone else's toes.
2. After the project ships, I can look at feature X in the product and get a good feeling, because I produced it.
3. If any critical bugs turn up just before shipping, I can fix them in super-quick time.
4. I can pretty much work the hours I like, without having to fit around anyone else.

This all contributes to my feeling happier at work, which makes me dramatically more productive.

The counter-argument "what if you're incompetent or get hit by a bus?" is easily overcome: just have frequent code reviews, where all the project's developers review everyone else's code.

In practice, every "interchangeable" project I've seen so far ends up with person X being well-known as the expert on part Y of the system. It just makes sense to recognise and/or formalise this at the start of the project.

Friday, September 5, 2003

[In practice, every "interchangeable" project I've seen so far ends up with person X being well-known as the expert on part Y of the system. It just makes sense to recognise and/or formalise this at the start of the project. ]

Well, experience often differs, of course, but I can't disagree with this more. Our project has gone 2.5 years without code ownership setting in, so I guess that explains my p.o.v.

As a general question, why is it necessary to "own" a specific part of an application in order to feel pride of workmanship? Why is it not possible to feel that with respect to the entire product?

Also, I find the mode of thinking that reasons that a developer can work on code they own "without worrying about stepping on other peoples toes" to be scary and, in my experience, dangerous. Unless you are working alone, developing software is ALL about working with others to make sure you don't get in each others way. Isolating yourself so you don't have to deal with others is essentially trying to turn a multi-developer project back into a solo effort.

Friday, September 5, 2003

Anon - agreed that developer fiefdoms are bad. However, you missed the point - we're guessing Joel isn't advocating fiefdoms, just pointing out that you can't put Fred in Daphne's chair and expect the timeline to be unchanged. He's not saying "don't do it" - just understand the impact of doing it.

"Developers are human too. They don't like being tied down to a particular piece of code any more than a mechanic would enjoy being told he could only fix tires"

LOL! You've worked with some enlightened individuals, my friend. If allowed, a LOT of developers want to "own" their code and treat trespassers with hostility. (At Camel the guy who became "King of the Database Schema" actively repelled attempts to review or assist with his designs).


Friday, September 5, 2003

I'm not even sure collective code ownership is the goal of all enlightened individuals.  Maybe all groups of enlightened individuals -- but when you have the possibility of random incompetents creeping in to your project, and as a fellow developer don't get the option to fire them, it's nice to at least have the option to say "Oh, that extension to system X should really be done by Bob, he did the original system X work."  [Translation: "I have looked at system X, in the course of trying to do something about the large number of bugs I've reported against it over the years.  And while I *can* read it, it burns my eyes.  If I had to face that task every morning I'd cry."]  Depending on the situation, of course, I might have the luxury of volunteering to "add to" / rewrite bits of / refactor system X.  But then again, I might not.  The fastest way to fix or extend existing code is to get someone who knows it well to do it.

I will agree.  It isn't an ideal world value at all.  That whole line of reasoning is pretty horrid.  But I've never worked with 100% competent people, and some days I'm not sure I ever will.

And I agree with the people who think some specialization is a good thing.  Not in the sense that the 'specialist' fends others off with pitchforks, but in the sense that he'd be perfectly willing to explain but everyone got bored and wandered off.  Not everyone on the team has to be fascinated with file formats or crypto or whatever, but it comes in handy if someone is.

Friday, September 5, 2003

> At Camel the guy who became "King of the Database Schema" actively repelled attempts to review or assist with his designs

Yep, I agree with Philo here; from what I've seen, this is the most common mode of development.

It's rather like house ownership: someone "owns" a section of code until they leave or get transferred, whereupon the code is given to a new owner, who gets the right to make pretty much whatever changes they like (there are always ways to justify them).

I like the "code communism" that XP advocates, but I've rarely seen it in practice.

Peter Breton
Friday, September 5, 2003

[LOL! You've worked with some enlightened individuals, my friend. If allowed, a LOT of developers want to "own" their code and treat trespassers with hostility. (At Camel the guy who became "King of the Database Schema" actively repelled attempts to review or assist with his designs). ]

Perhaps. I like to think so. :)

I do understand what Joel is saying, though. And, of course, we don't have 100% collective code ownership. People naturally have preferences and have spent more time in an area simply by chance. That's cool. But having a "go to" guy in one area is a long way from assigning ownership. So, we agree, I think.

We (developers) always tend to look for the edge cases. So, when XP says collective code ownership is good, someone immediately finds a case where it may not be such a bright idea. Usually, those cases are pretty obvious and taken as understood. Only fanatics espouse strict conformance with a process (everyone should have a bumper sticker: "Your process is not a death pact").

Friday, September 5, 2003

I think that one major problem in many programming environments (and indeed, is a career problem of many in this field) is the "groomed specialist". The person who is blithely unaware of the overall user environment, and/or the person who is shielded (or shields themself) from specialized kinds of code or design problems. This could be the EE hardware oriented type who thinks user interfaces are below contempt, or the user interface developer who goes out of their way to not understand threads or APIs to external communication paths.

The people who are shielded or shield themselves from any diversity are the ones who wind up as Wal-Mart greeters when they are laid off.

I also agree that joint code ownership isn't very implementable in practice for the reasons mentioned. However, I think it does most professionals a world of good to grow a bit personally and see another aspect of their occupation. There should be cross fertilization, but I believe that "real professionals" should be encouraged to consider it a good idea.

Example: I am developing an internet architecture of sorts for my client. My client's people (and indeed, the chief decision maker) are *scared to death* of anything online - whether it be usage ("look at all those virus attacks online!") or code wise.  These people are *only* workstation software developers by choice.  If I showed them a thread based application or an application that uses FTP or winsock functionality, their heads would probably explode. In this instance, I would welcome the opportunity to show any of the client's people the general territory of the solution I'm providing. Instead, I am absolutely indispensable in this role and they will only learn what they need at a button pushing level at the last possible moment.

Lastly, cross-fertilization should not just be technical. The more mature technical types should be acquainted with the "real" business environment that their employer operates in. By "real" I don't mean a sanitized and idealized view of their market, I mean the actual basic decision making process by which clients or customers use their employer's product or service...

Heads down is bad. It's for blue collar types, not professionals.

Bored Bystander
Friday, September 5, 2003

I dunno. I guess while everyone was standing around agreeing on how impracticable/hard/unnecessary/evil collective code ownership was, we just went ahead and did it.

It wasn't hard. There wasn't any wailing or hair pulling. No one came to the office with a rifle. All we did was move developers around each iteration. Now, it's almost wierd if a developer works on the same area for two iterations running.

It's not that code ownership doesn't work. Of course it does. It's not even that bad. The hidden trap is that, given a chance, many developers will work to create their very own solo development environment. And then you end up with Philo's Database Troll. I'd think you'd want to try to avoid that if at all possible.

Friday, September 5, 2003

I'm reminded of a story an older engineer told me at my first job.  He used to work at GE doing defense contract work.  At that job, there was a very common practice of completely shuffling teams to different projects every 6 months or so.

Was this to keep the engineers excited about new work?  Was this to avoid developing knowledge areas that only one or two people knew about?


It was to ensure that the contracts took much longer to finish, thereby keeping the money flowing in.  It's much easier to extend an existing government project than to get a new one.

Friday, September 5, 2003

BB wrote, "I think that one major problem in many programming environments (and indeed, is a career problem of many in this field) is the "groomed specialist"....

...Heads down is bad. It's for blue collar types, not professionals."

Well, the truth is many (most?) so called professionals are specialists! 

There a lots of mature and complex fields where occupations are both stratified and specialized.  In the construction industry, architects and engineers produce the plans that are built by general contractors.  General contractors typically subcontract parts of a job to specialty contractors such as plumbers, electricians, and landscapers.  In many engineering disciplines, professional engineers are supported by engineering technicians and technologists.  In medicine, you have doctors who are specialists, physicians' assistants, registered nurses, licensed practical nurses, and nurses aides.  In law, you have attorneys who are specialists, paralegals, and legal secretaries.

One Programmer's Opinion
Friday, September 5, 2003

As Heinlein once wrote: "Specialization is for insects".

Friday, September 5, 2003

"In law, you have attorneys who are specialists"

An interesting, nitpicky, semantic aside - this is not true. Attorneys are generalists by law. Rules of ethics forbid an attorney from claiming "specialization" in an area unless there is a specific accreditation for that area (Patent law being the big one).
There are sanctioned ways to work around it ("twenty years personal injury experience"), but the phrase "specializing in" is generally either forbidden or strongly discouraged (depending on the state)

There is no specialization in law school, and the bar exam covers all the major areas of law. Another one of those things I think it interesting that almost no lay people know.


Friday, September 5, 2003

*  Recent Topics

*  Fog Creek Home