Some developers hate XP - do they???

[Kishore Dandu]

According to some developers who do software development inhouse, they hate doing it the XP way(since they don't like being paired with some unproductive, lazy counterparts).
Waiting expert opinions on this issue.
Kishore.

[Lasse Koskela]

Understandable. They're not interested in doing all the work while the partner is picking his nose... This isn't a problem of XP; it's a problem of the organization in question.
Why aren't these lazy, unproductive counterparts kicked out of the payroll? Perhaps a renewal of staff incentives would be in place? Something like, say, making peer reviews matter most in annual bonus/raise/promotion decisions

[Ilja Preuss]

By the way, you are *not* "being paired" in vanilla XP - you *choose* yourself whom to pair with. So, if two people don't like to pair with each other, it shouldn't be that much of a problem. And if you have a "Wally" in your team noone likes to pair with, you might have a problem wether you do pair programming or not.
When management is forcing people to pair with each other, it's a big indication that they don't really understand what XP is about!

[Jeff Langr]

Most developers hate something or another. For example, I hate sitting in unproductive meetings, or producing reams of useless documentation. I hate using inadequate tools to do things like track time down to the minute. I hate when the team fails because a single developer is underperforming and producing poor quality work (and no one is aware of that fact until it's too late).
Processes and their attendent practices are about helping you to deliver quality software on time. If a practice detracts from that goal, question it and perhaps find something better. If you hate a practice, it is likely to be ineffective.
Pairing exists to provide better quality software through review. Part of this improvement comes about through constant context switching: if pairing correctly, you request a different partner every few hours. The new partner must be able to rapidly come up to speed, otherwise pairing would be ineffective. This forces you to start developing software that is more readily understand and thus more easily (cheaply) maintained.
If pairing isn't an effective choice for your shop, you should supplant it with a rigorous review practice, such as Fagan inspections. If you do neither pairing nor some other kind of formal review, you'll pay for it down the road.
My personal experience with pairing: upon learning about XP (c. 1999), I hated the idea of pairing. The thought of sitting with someone else all day disturbed my sense of being a hot-shot that came up with great, creative code. But I was intrigued enough with XP to give it a try.
After pairing for only a short time (a couple weeks), I recognized the value it brought: Far better quality design and code. I realized that it's too easy for an individual to accept a poor, costly solution as "good enough." Yet pairing was still my least favorite practice from XP.
It didn't take long after that before I came to truly enjoy pairing. There is a social aspect to it, obviously. The interaction with someone keeps you engaged with solving a problem. You are less likely to wander off to something else like web-surfing or posting to JavaRanch (no, I'm not pairing now). A day of pairing is productive, satisfying, and exhausting.
After a bit of pairing, I realized that my designs/code weren't as perfect as I previously thought. The new insights and approaches I learned helped better me as a software developer. I wouldn't have learned these from just looking at other peoples' code. My newfound humility was good; pairing made it better, since I now always had someone to validate my work. This side-effect provided me with a lot more comfort and confidence.
With respect to your question, one of the goals of pairing is to get all developers on the team to a competent skill level. You will always be dependent upon your team members for project success. When pairing, these team members should improve rapidly in their capabilities and understanding of the system. When not pairing, these team members might learn to get better on their own, or they might not.
Yes it's painful, but it will demonstrate whether or not these developers belong on the team. I'd rather find out in a few weeks than late in the game that they were only capable of producing garbage. And no matter how good you are, you'll learn something from even the most junior developers on a daily basis.
Some additional benefits of pairing:
* eliminates the "hit-by-a-bus syndrome"
* allows you to work in all areas of the system, which should build your resume
* paces your development, which will help in your estimation ability
* allows "cross-pollination" of development teams
* allows you to come up to speed and be productive very quickly without having to sit and read (usually inaccurate) manuals
* can be used as an effective interviewing mechanism
Above all, a team that is pairing properly quickly gels into a successful team that works exceptionally well together.
All this is not to say that there aren't problems with pairing. But before being dismissive of it, recognize the potential benefits that your development team (and management) can get out of it.
Jeff

[Ilja Preuss]

Jeff, outstanding post!
Your last point, about making a team gel, is very easy to underestimate. Our team is now doing pair programming (for about 50% of the time) since several months, I feel like I am just beginning to experience what *real* team work really means...

[alex ross]

I don't like the rule of pair programming, in fact, it is the most strange practice rule in XP. Who would like to be gazed at when he's at work? Peer review is good enough.
[ March 31, 2004: Message edited by: xp here ]

[Lasse Koskela]

Welcome to the JavaRanch!

Originally posted by xp here:
I don't like the rule of pair programming, in fact, it is the most strange practice rule in XP. Who would like to be gazed at when he's at work? Peer review is good enough.

The point is that you are working together, not under surveillance. If the attitude is to "pick at each other for every error you make when typing", you've got to solve that problem before you can even think about improving your team's performance.
By the way, you might want to edit your display name after you've read our naming policy.

[alex ross]

Sorry, I didn't notice the naming policy, I corrected already.
As for pair programming, in fact, I did something like that previously, but not for error checking, we sit together because we want to discuss the system design and see the result together. In XP, pair programming seems to be considered as an effective method for error checking, this is what I don't agree with.
I don't think pair programming could be adopted as a formal development method, firstly, boss don't agree to have persons doing the same work while they occupy two positons in the payroll. Secondly, how can you ensure pair programming will improve the performance rather than reduce it? Except special situation, generally people doing creative design - especially skillfull designers - don't like to be disturbed during his thinking, it's very hard to have two persons haveing the same work style, rhythm and thinking, so it's very hard to forsee the result after you force two guys with different experiences and skills sit together doing a same task.
[ March 31, 2004: Message edited by: alex ross ]

[Lasse Koskela]

Sorry, I didn't notice the naming policy, I corrected already.

Thanks.

In XP, pair programming seems to be considered as an effective method for error checking, this is what I don't agree with.

Well, pair programming also helps in design and spreads knowledge and skills among the project team (reduces project risk).

I don't think pair programming could be adopted as a formal development method, firstly, boss don't agree to have persons doing the same work while they occupy two positons in the payroll. Secondly, how can you ensure pair programming will improve the performance rather than reduce it?

In fact, pair programming has been around for decades and there has been some research on it. Google for Laurie Williams and you should find a lot of papers that show how pair programming (or pair whatever) has in fact improved overall performance. The problem is that typical bosses are too busy thinking about next week's golf game that they can't be bothered to read about what's happening in their profession.

Except special situation, generally people doing creative design - especially skillfull designers - don't like to be disturbed during his thinking, it's very hard to have two persons haveing the same work style, rhythm and thinking, so it's very hard to forsee the result after you force two guys with different experiences and skills sit together doing a same task.

Yes, it takes a conscious effort to learn to pair effectively. And yes, it's true that Senior System Architects (with capital S's and A's) might not like to be "disturbed". This is exactly why one of the rules an XP team must obey is "leave your ego on the door"...

[Warren Dew]

Originally posted by Lasse Koskela:
And yes, it's true that Senior System Architects (with capital S's and A's) might not like to be "disturbed". This is exactly why one of the rules an XP team must obey is "leave your ego on the door"...

Actually, if they are purely Senior Systems Architects and not Senior Systems Engineers, they shouldn't be pair programming because they shouldn't be programming at all.
If they only have the title "Architect" because the engineering pay scale doesn't go high enough, then they probably aren't really Systems Architects at all ... not to mention that the company's pay scales are probably out of whack.

[Lasse Koskela]

Yeah, it's the age old problem with those "architects"

[Lasse Koskela]

Please don't take my words as an attack against architects in general. I do respect experienced software professionals as long as they know what they're talking about. Unfortunately not all architects do. I've seen a few who couldn't even type...

[Ilja Preuss]

Originally posted by Warren Dew:

Actually, if they are purely Senior Systems Architects and not Senior Systems Engineers, they shouldn't be pair programming because they shouldn't be programming at all.

If architects aren't involved in implementing and using the architecture, how do they know that their architecture is a good one???

[Ilja Preuss]

Originally posted by alex ross:
In XP, pair programming seems to be considered as an effective method for error checking, this is what I don't agree with.

Where did you get this from???
The reason for doing PP in XP is that two heads are so much better being creative than one head alone. "Error checking" is just a side effect - we do write tests for this. (PP helps very much in being both disciplined and creative in writing tests, though.)

I don't think pair programming could be adopted as a formal development method,

It doesn't need to, it just needs to be adopted as a personal development technique, such as using an IDE, writing tests, brushing one's teeth...

firstly, boss don't agree to have persons doing the same work while they occupy two positons in the payroll.

Perhaps your boss could agree to a small experiment? Ours accepted two developers pair programming around 50% for two weeks. We weren't slower than before, so we were allowed to continue. The results were convincing enough that today it's fully up to us developers how much we pair program.

Secondly, how can you ensure pair programming will improve the performance rather than reduce it?

You can't. What you can do is try, observe and learn.

Except special situation, generally people doing creative design - especially skillfull designers - don't like to be disturbed during his thinking, it's very hard to have two persons haveing the same work style, rhythm and thinking, so it's very hard to forsee the result after you force two guys with different experiences and skills sit together doing a same task.

Pair Programming is a skill that needs to be learned like any other. Well, perhaps not like any other, as it is mainly a *social* skill. It can be learned though, and if you try you might be surprised by who will like it once he gets used to it.
One of my coworkers, in some sense a genius, liked to stare at the wall for two hours after he got a new assignement, after which he would just code down what he thought of and it would work. Literally.
Pair Programming with him wasn't easy at the beginning, but we were willing to give it a try and wouldn't throw in the towel prematurely. Today, he is one of the most enthusiastic about pair programming in the team.

[Warren Dew]

Originally posted by Ilja Preuss:
If architects aren't involved in implementing and using the architecture, how do they know that their architecture is a good one???

I don't think buildings are improved if the architect gets into the crane to help put girders into place. While it might be a learning experience for the architect, I'd worry that the resulting building might not be sound, since even building architects are rarely competent crane operators. I'd prefer that the architects get their experience some other way, such as in their education and by previous service as a junior architect. That goes for systems architects as well as building architects.
I think a lot of software people don't understand what a systems architect - or what architects in general - are actually supposed to do; they misunderstand "architect" to mean just "high level systems/software designer". Heck, I held that misunderstanding for a long time. I only figured out there was another meaning for 'architect' when I was in a group which actually had someone who had the title Systems Architect - but who had been hired by a manager who thought that meant "high level designer". The programmers resented the architect because he wrote code with great reluctance and didn't do it very well, and the designs he did do seemed simplistic to us. The architect wasn't too happy either, because in fact the designs he was being asked to do were systems implementation designs, not the systems architecture he was good at: the architecture was already done, and the manager's boss kept for himself the few necessary changes, leaving little for the architect to actually work on.
Here's some excerpts from Brooks' "The Mythical Man-Month" that I think clarify things. (Interestingly, this book was recommended to me by the very manager mentioned above, who was actually an excellent software manager.):
"By the architecture of the system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a control program it is the manuals for the language or languages used to invoke its function. For the entire system it is the union of the manuals the user must consult to do his job....
"Architecture must be carefully distinguished from implementation. As Blaauw has said, 'Where architecture tells what happens, implementation tells how it is made to happen.' He gives as a simple example a clock, whose architecture consists of the face, the hands, and the winding knob. When a child has learned this architecture, he can tell time as easily from a wristwatch as from a church tower. The implementation, however, and its realization, describe what goes on inside the case ..."
And here's his analysis of the tensions between architects and implementors:
"When it is proposed that a small architecture team in fact write all the external specifications for a computer or a programming system, the implementers raise three objections:
- The specifications will be too rich in function and will not reflect practical cost considerations.
- The architects will get all the creative fun and shut out the inventiveness of the implementors.
- The many implementers will have to sit idly by while the specifications come through the narrow funnel that is the architecture team.
"The first of these is a real danger, and it will be treated in the next chapter. The other two are illusions, pure and simple. As we have seen above [in previous chapters], implementation is also a creative activity of the first order. The opportunity to be creative and inventive in implementation is not significantly diminished by working within a given external specificaion, and the order of creativity may even be enhanced by that specification....
"The last objection is one of timing and phasing.... In computer design, for example, the implementer can start as soon as he has relatively vague assumptions about the manual, somewhat clearer ideas about the technology, and well defined cost and performance objectives. He can begin designing data flows, control sequences, gross packaging concepts, and so on."
I'd note, too, that having separate architects is probably anathema to XP techniques, where the user interface is supposed to emerge organically from the development process, rather than be dictated by formal functional specifications. On the other hand, I suspect much of the waterfall development process' current bad press is due to attempts to use that process without a full understanding of the difference between architecture and implementation, and the resulting counterproductive attempts by architects and implementors to do each others' jobs instead of their own.

[Stan James]

It's interesting how many different things "architecture" means to people. I'm an application architect by job description right now, and UI design is about the least interesting thing to me. Introducing Active-X controls to a web app would get my attention, but button text and page layouts do not.
I think the "highest level design" type of definition would find more acceptance today, though I have trouble with "high" some days. I figure my job deals first with the number and types of components we have, how they share or divide responsibilities and how they communicate. Next with the partner systems we talk to - 60+ external calls to 20+ partners. I help decide if a new partner will work with existing protocols or require something completely new. I also mix in a healthy bit of OO design principles and coding quality, just because that's stuff I care about.
Here are some Architecture Pages I put together. Included is a link to zillions of Definitions of Architecture at SEI. The word is overused to the point of being nearly meaningless out of a specific context.
Back to your point about architects coding or working with their own designs - it sure helps people at my level of architecture. I did major design on a couple systems in the 90s and left the team as soon as they were running. I did a lot of coding, so I know they were buildable, but I have no idea if they were maintainable, and that was certainly a success criteria when I started out. Makes it hard to learn from your mistakes. Lately I've been too far from the code, and I don't know if my design decisions give developers huge benefits or huge pain until they're well into building something.

[Warren Dew]

It's to be noted that object oriented software engineering has done much to blur the distinction between architecture and implementation. In Java, for example, any well documented class has an explicit architecture - for example, the JavaDoc for java.util.List provides the architecture for java.util.ArrayList and java.util.LinkedList. Object oriented languages, by partitioning code into classes and making interfaces enforceable by the compiler, facilitate architecting of the code at a much lower level than used to be common practice. And because architecting of application specific classes is part of the implementation of the overall application, it's not clear whether someone who does this work is an architect (of the classes) or an implementor or engineer (of the application).
While I agree with Brooks that there's plenty of creativity in the implementation of a project when the architects stick to the architecture of the overall project, I do also agree that objections to "architects" that want to architect every individual class but not to actually code can be legitimate: they may indeed really be engineers that do want to do only the fun stuff.

[alex ross]

XP does provide some natural ideas on software development, and as a matter of truth, many developers were aware of that due to the limitation of man's ideation, details should be discovered step by step. Based on this fact, many iterative processes were devised, such as UP and XP. Besides, XP created a set of practice rules to guide the actions of developers.
But the problem is, while bringing some benefits into developments, each method brings some side effects also. For example, the benefits of pair programming may include: knowledge distribution, fewer error prone. The questions about PP include:
1. Does it really need so many continual communications in coding?
2. Does the partner can always grasp the meaning of each line or function of another guy in time?
3. Can we ensure while one guy is busy in typing, another guy is not in idle?
I think these questions may reflect that at least the form of PP is not yet clearlly defined. Under an extreme condition, frankly to say, when good experienced and inexperienced guys pairing, the PP would rather work as a process of training instead of cooperation. Even this may be a benefit of pair programming, but we can't say this is the only way of training.
As for the role of architect or designer, I think it may not be a problem. Any qualified designer should be good at programming also, it's hard to imagine without a scenario of the system in mind, one can make a good design. And in most cases, it's the responsibility of an architect (or with help of other developers) to programming the prototype and maintain it when change is nessasory. In most projects, we do need guys with good knowledges and sufficient experiences to be responsible for decision-making and hold a global view of the system.
Personally, I'm not proficient in XP, so I think PP may be one of the natural method derived from XP, but I just suspect it's the only or most efficient method. Additionally, I have some questions about iterative methods, I wish to get some tips from masters:
1. How does iterative method solve the dellimma of early cost estimation and defered detail dicovering?
2. Are there some experiences to prove refactorying could lower the cost of defered modification?
3. How to share sorce code in XP without some guys mess it up?

[Lasse Koskela]

programming may include: knowledge distribution, fewer error prone. The questions about PP include:
1. Does it really need so many continual communications in coding?
2. Does the partner can always grasp the meaning of each line or function of another guy in time?
3. Can we ensure while one guy is busy in typing, another guy is not in idle?
I think these questions may reflect that at least the form of PP is not yet clearlly defined.

1) Maybe. Maybe not. But we'll never know until we've crossed the point of diminishing returns. The point of optimization in general is to change the status quo, not preserve it...
2) If he doesn't, it's a high time to ask the driver what is the function doing.
3) Here's a quote from one of Laurie Williams' essays: The programmers admit to working harder and smarter on programs because they do not want to let their partner down. Again, if the pair programming session is becoming pure silence, it's time to pass on the keyboard.
If you're interested in reading about pair programming reports, you might want to check these out: (and, of course, pairprogramming.com)
Strengthening the case for pair-programming
The costs and benefits of pair-programming
Program quality with pair-programming in CS1
Empirical studies of pair programming
When does a pair outperform two individuals?
Experimenting with pair programming in the classroom
The impact of pair-programming on student performance, perception and persistence
A pair programming experience

1. How does iterative method solve the dellimma of early cost estimation and defered detail dicovering?

Could you explain this dilemma to me? Are you referring to iterative methods losing out in early cost estimation due to deferred detail discovering?

2. Are there some experiences to prove refactorying could lower the cost of defered modification?

Can't provide any references although I'm pretty sure Google would find you a nice bunch of conference papers...

3. How to share sorce code in XP without some guys mess it up?

By sharing it often, in small pieces, and by communicating what you're doing. "I'm moving all this XML parsing stuff into a new package" takes about 2 seconds to say out loud in the room and saves more than that in terms of "hey, where's all that parsing code I wrote yesterday?" type of questions (which don't take too many seconds to answer, either, assuming everyone are nearby)...

[alex ross]

By 'dellimma of early cost estimation and defered details discovering' I mean without sufficient details of design, how do we estimate the cost and plan the resource usage for development, both these plans should be made before development begins, and both customers and managers need buget plan based on them. But with interative process, many details are defered, so it may not easy to control the scope. This is a dellimma.
Thanks Lasse Koskela provided so many valuable articles. I read them and besides, I read some discussions and surveys on internet about XP. It seems that XP are accepted by part of developers while there are others are still skeptical to it. For XP, There are still a number of presumptions for its usage, C3 and some projects from universities got good result with XP, but there are still few surveys on XP in compare with other methods from industry. And this may be what we need as well.
Besides, here are some amusing pictures I got from www.pairprogramming.com, the left side are pics drawn by solo, pics on the right side are drawn by paired guys. I don't know what pairprogramming want to say by that, maybe it's not suit for art design


[ April 05, 2004: Message edited by: alex ross ]

[Warren Dew]

Originally posted by alex ross:
By 'dellimma of early cost estimation and defered details discovering' I mean without sufficient details of design, how do we estimate the cost and plan the resource usage for development, both these plans should be made before development begins, and both customers and managers need buget plan based on them. But with interative process, many details are defered, so it may not easy to control the scope. This is a dellimma.

My impression of strict XP, which admittedly is more from reading and using a few of the techniques than from using them all at once, is that an XP team solves the cost estimation 'dilemma' by turning it around: if the client needs a budget, simply agree on a budget, and when you've spent it, you're done.
Why does this work for XP? Because there's an insistence that at every iteration, you're delivering something of value to the client. That means that at any point in the budget after the first iteration - which is after the first week, which is an amount easy to estimate for - the client has received value for his money. He can always receive more value for more money, but he can always stop spending and be satisfied with the value he's received so far.
I personally don't think that this works for every project, but I think it can be made to work for most of them.

[Ilja Preuss]

Originally posted by alex ross:
Besides, here are some amusing pictures I got from www.pairprogramming.com, the left side are pics drawn by solo, pics on the right side are drawn by paired guys. I don't know what pairprogramming want to say by that, maybe it's not suit for art design

Well, the right ones certainly look less boring and more creative, don't they? They might even get mistaken as picassos...

[alex ross]

Originally posted by Warren Dew:

My impression of strict XP, which admittedly is more from reading and using a few of the techniques than from using them all at once, is that an XP team solves the cost estimation 'dilemma' by turning it around: if the client needs a budget, simply agree on a budget, and when you've spent it, you're done.

So this will much depend on the convention of finace and management style, we must take that factors into account before we do this.

Originally posted by Ilja Preuss :

Well, the right ones certainly look less boring and more creative, don't they? They might even get mistaken as picassos...

Hehe, I think picassos should enjoy the right ones, but at the same time, he may still need the left ones as a reference.

[Ilja Preuss]

Originally posted by alex ross:
By 'dellimma of early cost estimation and defered details discovering' I mean without sufficient details of design, how do we estimate the cost and plan the resource usage for development

An XP team does it the following way:
The first few days of a new project are used to gather requirements in the form of User Stories. A Story is a piece of functionality whith business value for the Customer that can be implemented in a few days. The story is given a rough estimate - a value between 1 and 3, where 3 means that the Story will take thrice as long as a 1. That estimate is mainly based on gut feel and possibly some small experiments.
Then the Customer prioritizes the Stories based on estimated cost and business value. Based on that information, the team creates a first rough Release plan (the team might have some knowledge from prior projects on how long a Story Point will take them, or they just guess).
The team then starts the first iteration by implementing the Stories with the highest priorities. At the end of the iteration they observe how many Story Points they actually implemented and use that information to calibrate the Release Plan. They continue so that the every couple of weeks the Release Plan gets more accurate.
So, when a more conventional team would have produced a detailed requirements document and design to use for estimation, the XP team already has implemented the most important functionality. Nevertheless the XP team also can tell you a delivery date for the whole project - as experience seems to suggest typically as reliably as the more conventional team. At the same time it has invested less into the future and already delivered more value to the Customer.

[Ilja Preuss]

Originally posted by alex ross:
The questions about PP include:
1. Does it really need so many continual communications in coding?

XP developers don't just code - they always test, code and design at the same time. This is a creative process, which is very much fostered by PP.

2. Does the partner can always grasp the meaning of each line or function of another guy in time?

If he can't, there is something wrong with the code that needs to be fixed.

3. Can we ensure while one guy is busy in typing, another guy is not in idle?

There is always something to think about. If one of the two programmers isn't fully involved into what the pair is doing, there is something else wrong, I'd guess.

I think these questions may reflect that at least the form of PP is not yet clearlly defined.

With all due respect, I think that they reflect more about your knowledge of PP.

Under an extreme condition, frankly to say, when good experienced and inexperienced guys pairing, the PP would rather work as a process of training instead of cooperation.

I don't think so. The experienced one is likely to still learn something from the less experienced. Also, there is more to PP than simple knowledge transfer.
There is this story of Kent Beck programming alone at home and his daughter looking into the room every couple of minutes, asking "Do you have a test for that?"...

Even this may be a benefit of pair programming, but we can't say this is the only way of training.

But you also can't say wether it is an effective one until you have tried it!

In most projects, we do need guys with good knowledges and sufficient experiences to be responsible for decision-making and hold a global view of the system.

Yes, certainly. It doesn't necessarily need to be a guy with a specific job description, though.

Personally, I'm not proficient in XP, so I think PP may be one of the natural method derived from XP, but I just suspect it's the only or most efficient method.

I am not sure I understand you here...

2. Are there some experiences to prove refactorying could lower the cost of defered modification?

Myriads of anecdotal evidence. No prove, though.

3. How to share sorce code in XP without some guys mess it up?

Write tests which bail when the code is messed up. Pair Programm with your coworkers. Work with guys who have pride in their work and like to create quality. Make it easy for your coworkers to ask for help if they feel unsure about something.

[Ilja Preuss]

Originally posted by Warren Dew:
It's to be noted that object oriented software engineering has done much to blur the distinction between architecture and implementation. In Java, for example, any well documented class has an explicit architecture - for example, the JavaDoc for java.util.List provides the architecture for java.util.ArrayList and java.util.LinkedList.

Here you seem to be saying architecture = contract? That seems to be qutie different from Brook's architecture = UI specification, doesn't it?
BTW, Martin Fowler has another quite different take on architecture: http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

Object oriented languages, by partitioning code into classes and making interfaces enforceable by the compiler

That would be statically typed languages. Dynamically typed ones, like Smalltalk or Ruby, don't enforce interfaces at compile time.

[Warren Dew]

Originally posted by Ilja Preuss:
Here you seem to be saying architecture = contract? That seems to be qutie different from Brook's architecture = UI specification, doesn't it?

Not at all. In fact, in this case, they are exactly the same thing. The document that is the User Interface (UI) specification for the user of a system - in this case, the user of the java.util.List subclass - is also the contract for the developers who implement the system - in this case, the programmers who wrote the code implementing java.util.ArrayList and java.util.LinkedList.
When I write code that uses a java.util.ArrayList, I'm not an implementor of the List, I'm a user of it. For me, the Javadoc for java.util.List is a user interface specification - a specification of the interface for the benefit of users like me. It only becomes a contract for me if I'm implementing a List subclass - only then am I bound by the Javadoc to write the List in a way that might differ from how I would otherwise write it. But it's still the same document.
A "contract" as the term is now used by software engineers only differs from Brooks' "complete and detailed specification of the user interface" when it leaves significant portions of the interface undefined - so that it's no longer "complete and detailed", and ends up imposing requirements on the user to avoid certain uses of the system or to experiment to see how they work - or, when it's expressed in a way that's not geared towards users - such as when it's expressed in terms of tests only - or, when the implementation doesn't actually match the contract.
As for Martin Fowler's take, I think Brooks' definition is entirely consistent with the IEEE definition that he quotes, though phrased very differently. While Fowler obviously doesn't like the IEEE definition, I think that's because he doesn't really understand that definition - much as many of the detractors of pair programming don't like the concept of pairing because they don't really understand what it actually means. And the fact is, you don't have to understand something if you don't use it, and neither explicit architectures nor pair programming are absolutely necessary to a successful project - there are other ways of getting the work done.

That would be statically typed languages. Dynamically typed ones, like Smalltalk or Ruby, don't enforce interfaces at compile time.

I was hoping that, this being a Java forum, no one would call me on that, but of course you're right. In fact, the main reason I prefer statically typed languages for systems of moderate complexity and above is exactly that they allow more of the architecture/UI specification/contract/whatever-term-you-want-to-use to be enforced as early as possible.
[ April 06, 2004: Message edited by: Warren Dew ]

[Ilja Preuss]

Originally posted by Warren Dew:
When I write code that uses a java.util.ArrayList, I'm not an implementor of the List, I'm a user of it. For me, the Javadoc for java.util.List is a user interface specification - a specification of the interface for the benefit of users like me.

That's a usage of the term "user interface" I wasn't previously aware of. To me, a user interface is the interface between the system and its end user.
Anyway, the cited IEEE definition seems to speak about the interfaces the internal components communicate through each other, not the interface to the user.

It only becomes a contract for me if I'm implementing a List subclass - only then am I bound by the Javadoc to write the List in a way that might differ from how I would otherwise write it.

To the contrary, it's a contract between the component provider and the component user. It states what inputs the component accepts and what functionality it guarantees to provide. In fact, subclasses can even change the contract to some amount - specifically widen pre-conditions and narrow post-conditions. (The covariant return types supported by Tiger are a very specific case of the latter.)

As for Martin Fowler's take, I think Brooks' definition is entirely consistent with the IEEE definition that he quotes, though phrased very differently.

As stated above, I don't see how it is.

While Fowler obviously doesn't like the IEEE definition, I think that's because he doesn't really understand that definition

Well, it seems as if I still don't understand your usage of the term...

In fact, the main reason I prefer statically typed languages for systems of moderate complexity and above is exactly that they allow more of the architecture/UI specification/contract/whatever-term-you-want-to-use to be enforced as early as possible.

I mainly like what modern IDEs are able to do with hte type information.
Regarding enforcing the "whatever", I feel that type safety only plays a rather small role in ensuring correctness of a program. And the increased compile times actually *defer* other important checks, such as the running of unit tests. So I am far from convinced that static typing really is worth the price...

[Warren Dew]

Originally posted by Ilja Preuss:
That's a usage of the term "user interface" I wasn't previously aware of. To me, a user interface is the interface between the system and its end user.

I guess I would call that an "end user interface". Given that Brooks includes in his definition of "architecture" the phrase "For a computer this is the programming manual", I think it's clear he would include the Javadoc for Java libraries.

Anyway, the cited IEEE definition seems to speak about the interfaces the internal components communicate through each other, not the interface to the user.

I don't want to spend too much time defending the IEEE definition. While I agree with what it's trying to say, I don't think it's very well written; for example, it also talks about "highest level" interfaces, which would seem to exclude those internal interfaces, which brings up the question of why the internal interfaces are mentioned at all. I think that's because it's trying to make the point that what's architecture at a lower level can be implementation at a higher level, but I think it's difficult to glean that from the IEEE wording unless you're already looking for it.

Regarding enforcing the "whatever", I feel that type safety only plays a rather small role in ensuring correctness of a program. And the increased compile times actually *defer* other important checks, such as the running of unit tests.

The usefulness of static typing can certainly vary for different people or in different applications, but I don't see how this particular complaint can be valid. It seems to me that type binding has to be done either at compile time or at run time, so the total for compilation and running unit tests has to include it in whether it's done early or late. Am I missing something?

[Ilja Preuss]

Originally posted by Warren Dew:
It seems to me that type binding has to be done either at compile time or at run time, so the total for compilation and running unit tests has to include it in whether it's done early or late. Am I missing something?

Yes - Java needs to do method resolution at runtime as Smalltalk does - the byte code only contains the method signature.
But there might be more to it - might well be that type binding at runtime can be made less costly than at compile time?

[Thomas Paul]

Originally posted by Ilja Preuss:
There is economic value in manufacturing identical wheels. There is no economic value in reinventing the wheel. With manufacturing, variation is bad. With design activities such as software, variation (i.e. differences from previous systems) is what we're selling. -- Hubert Matthews

I just wanted to comment on this quote. I hope you realize that it makes no sense at all. Wheels are not identical products. Wheels from different manufacturers are different. That is called product differentiation. Manufacturers come out with new models on a regular basis. Sounds to me that Mr. Matthews doesn't know anything about the tire business.

[Ilja Preuss]

Originally posted by Thomas Paul:

I just wanted to comment on this quote.

Mhh, I think I already generated enough OT content in this thread....
Let's start a new one.