Mike Spille
Posts: 25
Nickname: mspille
Registered: Nov, 2002
|
|
Re: Design Principles and Code Ownership
|
Posted: Dec 3, 2002 8:20 PM
|
|
> > 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
|
|
Previous Topic
