Ralf's Sudelbücher

I think you got it wrong when it comes to the "will to control" in XP -- I think in most agile development processes (including XP) the idea is to move away from a single controling individual but rather teams working together and controlling themselves.

The fact that (mostly) anyone can jump into a piece of the software and change it is not a control freak feature, is a flexibility feature.

Poppendieck has a very good explanation of why agile methodologies work and how they compare to what happened in manufactoring e.g. Toyota became more agile than American car manufacturers and beat the crap out of them.

http://www.amazon.com/exec/obidos/ASIN/0321150783/poppendieckco-20/102-0796345-5504957

@Hector: Thx for pointing me to "Lean Software Production". I ordered it right away.

I´m all in favor for not betting everything on a single controlling individual. Of course software is a team effort. Of course high qualitiy software requires open communication among team members and input on problems from as many people as possible.

And it might even be ok for some developer to fix a problem in somebody else´s code - but then this developer should behave as a guest.

Flexibility of course is great! Processes and teams should strive for it. But I don´t understand why reaching flexibility should only be possible by giving equal rights and equal responsibilities and equal knowledge to everyone. This is unheard of in any other industry. And it somehow smacks of... well, some political ideology I don´t want to name here ;-)

Lean automobile production might mean a lot of things. But it sure does not mean, the person designing the motor is the same person who designs the car´s body. The guy designing the interior is not the same guy designing or building the electrical system of the car.

The same is true for building houses: There are masons, roofers, plumbers, carpenters, electricians and many more. And they all work very flexibly together while "producing" a house.

A physician seems to be a specialist. An engineer seems to be a specialist. With regard to laymen they might be. But in fact "physician" or "engineer" is not really (anymore) a specialization. Being a neurologist, a proctologist, an internist, a pediatrician - that´s a specialization. Likewise being an aircraft engineer or an electrical engineer or a mechanical engineer are specializations.

To a layman a software developer might look like a specialist. And he has been for a long time. But nowadays... The industry has developed too many technologies and tools and areas as to call a software developer or programmer a specialist anymore. A UI designer, a database designer, a tester, an architect, someone focussing on enterprise technologies, someone focussing on PDAs, a game developer - they are specialists. At least they would be, if those and many other areas were perceived as "special" enough. But they are not - at least by a large number of developers. Because they still harbor the illusion, they can know and master it all.

And exactly this kind of thinking is behind CCO. Resting on the premise of the possibility of omniscience CCO is trying to solve the flexibility problem. But I´m sure, in the end it will fail.

Please, get me right: I´m not against XP per se. Promoting (unit) testing, flexibility, refactoring is great! But that does not automatically make each and every XP notion a perfect solution.

I've found it much easier to do architecture within a team that practices collective code ownership. More team members have a greater grasp of the system as a whole because they're rotating through different areas of the system. That makes it much easier to communicate architectural ideas to your team members because they better understand the context of the decisions. It also seems to enable more people in the team to positively contribute to the architecture discussions.



And I'll add one more reason to your alphabet list:

g.) Can the team continue to function when a key team member is out for two weeks.

@Jeremy: I´m not saying, an architect should share his thoughts with the team. To involve the team during designing the whole system, modelling its components is good. And since I´m in favor for clear responsibilities, I think whenever contracts between components need to be "negotiated", then the "owners" of those components should be the ones to do it unter the supervision of the architect.

So the more responsibilties a developer has and the more the architect invites the team to "review" the architecture, the more everyone knows about the whole system.

But this positive knowledge about the whole is different from collective code ownership which means extensive knowledge of implementation details. This extensive knowledge runs contrary to any decoupling efforts during modelling.

Again: I´m all for communication and collaboration, asking co-developers for help, opening one´s thoughts to others. But that´s different from inviting everybody to work on any part of a system.

As for your thought g.: 1. How do other industries deal with this situation? 2. Why not plan for such situations and assign a backup developer? 3. As I suggested: Maybe even other developers can touch code in another responsibility domain - but then they are guest and behave like that. The never own it. And the owner - once he returns from his two weeks vacations - is responsible for reviewing whatever others have done to his code.

Maybe the software industry has to ackownledge it´s trying to do the impossible: build very, very complex products with a wrong view on the ressources needed.

You can´t have the cake and eat it: use evermore complex technologies to build evermore complex stuff - and use a project organization like 30 years ago. Sure, Agile Methods are to the rescue everywhere... but can they defy pretty simple logic and experience in other industries?

Software development is not even on par with other industries when it comes to using "components". Loose coupling, contract first design, IoC - it´s not widely in use. So I´d say: Since XP is not even about component orientation how can it make a statement about a component oriented production process? Components are about boundaries - in any industry. Collective code ownership does not recognize boundaries, because it favors free diseminattion of implementation details.

So CCO seems to be in contradiction with component orientation.

Please get me right: I´m all for flexibility and openness to contributions from any team member. But does that necessarily entail the absence of clear responsibilties?

But I´m getting carried away here... ;-) Also, the issue of non-CCO needs to be seen as just a part of a bigger picture. Software development needs to change in more regards - but the reason is all the same:

Software development needs to change in order to cope with higher complexity, higher diversity, more options, faster evolution, higher demands. Just advancing some tools and trying to keep everybody as informed about everything is futile.

How we organize projects, how we model software, how the market pays for software, how developers organize themselves - this all has to change - and I´m sure it will change within the next 10 years.

All I meant to say Ralf is that it is actually easier in many ways to be an architect on a team doing CCO. I wasn't trying to imply you were against the communication, just that I think communicating an architecture is easier inside a team that practices CCO.

Being able to build a system with loose coupling is mostly a matter of the technical skill and knowledge of the team more than any particular process or practice anyway. I would contend though that the practice of TDD within XP enforces/promotes the usage of loose coupling. XP certainly goes much easier when you take advantage of IoC/DI and other strategies for loose coupling.

I think the assignment of people to a specific part of the code versus CCO to be orthogonal to defining a solid separation of concerns. One thing CCO definitely contributes to is the elimination of duplication. I think knowing more about the system as a whole makes it easier to put related functionality in a consistent place.

As far as software trying to borrow from other industries, at some point I think we need to realize that software is its own thing. Trying to apply practices from manufacturing or construction too literally doesn't work. I was an engineer before I went into software development. The behavior of steel is easily predictable, software isn't. We need to create our own canon of software wisdom.

Now, whether or not a team practicing CCO needs to have a clearly defined architect or technical lead role, that's a different subject I'll leave to everyone else.

All in all a thought provoking post.

@Jeremy: I fully understand, it "feels easier" ;-) to be an architect on a CCO team. But I´d argue this so only at the beginning. The reason: Once the team starts and you do not have even have a microkernel framework and to strictly separated development of components, then the coupling of what you´ve design will start to increase. Slowly, but steadily as the developers carry over their knowledge of implementation details of one part of the software into all sorts of other parts.

So what I mean is: if software development agrees on components and loose coupling as having large value... then it´s only very consequential to support this by clear responsibilities as well as clearly separated development of components (in their own testbeds).

I like TDD quite a bit - as a "prototyping technique". TDD for me is useful to shape component contracts once you know which components a software system consits of. But TDD itself does not enforce loose coupling, I´d say.

Hm... why is "assignment of people to a specific part" orthogonal to CCO?

Avoiding duplicate functionality should not be something that somehow happens, but be the result of a planning process. But of course, duplication might creep in over time, so refactoring is necessary. But CCO is not - rather, it stands in the way of planning, I´d say.

Sure, not every practice from other industries can be applied to software development. And software development is different. But my feeling is, software development is so happy to be different, that it´s trying to resist the transfer of experiences from other industries more than is good for it.

Software quality cannot be calculated like the behaviour of steel or concrete. Software quality can only assessed empirically by testing, testing, testing. And of course XP thus is right by emphazising testing and refactoring. But CCO does not help here.

CCO and an architect role are orthogonal, from my point of view. Nevertheless I´d say: a software architect is a necessary role.

M8, I think you are missing the point of CCO completely. You are mainly talking about technology and frankly, no one developer will ever be an expert in every technology out there today. The field of software development is too big and wide for any one developer to have an expert understanding of the whole discipline. I personally believe you should have a good base to work from (Good OO understanding) and a general understanding of technologies available. Now, at the same time the team should spread the technology research between them.

In our company, we might have four or five projects running at the same time. We have SQL experts, but they also have general programming capabilities. Thus giving our team the ability the share the unique knowledge between project teams as needed and at the same time spreading the SQL knowledge through pairing with non-SQL experts when implementing specific SQL functionality. Thus, the project does not have a bus factor at any point. We have a concept of assigning specific technologies the company thinks it needs to invest in, to technology groups. These might be three or four individuals in a group to research and become experts in a specific technology.

On another point, when using TDD to drive your implementation and code, at some point if you have done it incorrectly, you will hurt. Why? Because you will have HIGH coupling between your object and you will start to feel the pain of fragile, breaking test. So what does this mean? Developers today still write procedural code. Go look at some of your code that you’ve written maybe yesterday, run a metrics tool like SourceMonitor over it, and if you find any code above 10 in Cyclomatic Complexity, I can guarantee you’ve written procedural code that is breaking some sort of OO rule.

The way TDD forces you to write loosely coupled code is through having to replace external dependencies in the class under test with Stubs or Mocks using Inversion of Control and Dependency injection. Moreover, because Mock frameworks normally can only mock interfaces, this will force you to communicate to the external component through an interface, which means you have low coupling between these two components. Knowing your Design Patterns will also help you to practice TDD more efficient.

On another note, I think you are also missing the relationship between the XP practices and the roles these practices play in supporting each other. If you look at CCO in isolation, you are missing crucial benefits you are getting when you look at CCO in context to the other practices. What do I mean? Well, all the practices of XP support each other and as a whole make developing software easier and more productive, reducing the risk of failure. Maybe you should have a read of this essay explaining this in more detail.

@Maruis: I don´t understand your argument. You support mine by saying "no one developer will ever be an expert in every technology" and go on to describe how your company keeps expert groups - but you don´t follow my conclusion. Why? If there are experts, then they naturally cannot (!) be qualified to work on each and every detail of a project. And just because experts hand down some knowledge to others by pari programming, the receiving developers don´t become experts themselves.

I´m also in favor of decoupling components and using IoC/Microkernels and Mocks. All great stuff. But what does it have to do with CCO?

If you´re a fan of TDD, great! Go for it. It´s one way of finding the best signatures for the interfaces you arrived at during modelling. Unless, though, you don´t explicitly model components (and not classes), I doubt your software has a sound architecture. But that´s a different matter.

Why I´m missing any relationship between XP practices? I´m not concerned with pair programming, refactoring etc. I was just focussing on CCO - which does not become just right by being tied in with other XP practices. And others are not invalidated just because I don´t think CCO is of much value.

I like XP - but XP is (or at least should not be) written in stone.

Ralf, rather than speculate at length about Agile and XP, why not actually earn some practical and empirical knowledge and experience?

You can’t guess at the nature of XP from a waterfall perspective – it’s like trying to figure out quantum theory from a perspective where the smallest unit of material decomposition is a molecule.

On an XP team, CCO is a must because an XP team goes fast! An XP team pairs, so knowledge is transferred quickly. An XP pair can change any code in the system. There is no "That's John's code". It's code, and it's in the system, and it needs to be changed - done.

I don't understand why you try to keep secrets about the code on your team. I can't imagine how your team benefits by confining a single developer to a small part of the codebase.

Friend, some of your "guesses at some of these XP premises" are slightly off..

1. Software development teams are highly volatile: ALL software teams are somewhat volatile. But

this is not the point. The idea is that everyone is responsible for the project. So before I make

a code change, I'm responsible enough to communicate with the other knowledgable project members

(daily stand up meeting, pairing, etc) to gain a level of certainty that the change is a good one.

After making the change I run the automated test suites to confirm that the quality of the of

project is maintained.

2. Changes to software need to be applied immediately: Bogus, no one ever said that. The idea of

agile is to try to reduce "blocking" as much as possible. So, if the responsibile developer has a

good feeling that the change is sound. They should be able to make they change him/herself and not

be blocked with "oh, I'll have to hand it to John, because he own's the code." or worse still, "I'll

make a change to the code I own, to work around John's code, because he's too busy to make the fix,

even though the change should be in his code area"

http://butunclebob.com/ArticleS.UncleBob.ThePrimeDirectiveOfAgileDevelopment




3. Specialization of developers is contraproductive:
http://www.agilemodeling.com/essays/generalizingSpecialists.htm

4. Software quality is primarily determined by functional correctness:

"The health of software"
Kent is interested in developing healthy and quality software emphasising that health is not the same as quality. Health is a continuous measure of the state of software while quality is an instantaneous measure of software at a point in time. Healthy software responds well to stress, e.g. making frequent refactorings and changes to the code. Having automated unit tests helps to make coding changes easier and gives developers courage and confidence to persist.
software.

6. Knowledge of implementation details should be maximized: their should be metaphors to describe the projects and sub-projects. The "courage" comes from the automated test, and "extreme" communications with the team, etc, not from knowing the code.

Your premise assumes that someone, somewhere has a clear vision of what the application will be and be intelligent enough to be able to communicate it to the rest of the team. That is rarely, if ever, the case.

Your premise also downplays the high cost of communication between these specialists as they hand-off their "clearly-defined" units of work to each other. The cost is high. Email, meetings and conference calls result in misunderstandings taking weeks rather than minutes to resolve.

Specialists only know they're toolset. If you only have a hammer, everthing looks like a nail. Database experts always look to solve the problem in the database. OO experts put everything in the model.

Specialists attempt to optimize for their own area, rather than optimizing for the system. DB experts make they're stored procuedures really efficient, but quite possible unusable by the middle-tier developers.

Given the current state of the world, I'll put my trust in a few generalists who are interested in working closely and learning from each other, rather than a team of experts whose focus is so narrow that they are unable to leverage other, more appropriate technologies.

@Jeffrey: What you´re telling me I already know. You´re just repeating the XP claim. But repeating this claim is no answer to my concern which I´m happy to list again: 1. There are too many technologies for one person to know enough to be able to produce quality code. 2. Spreading knowledge about source details runs against any means to decouple parts of software. 3. No other industry relies on "generalized specialists" to develop or produce products - isn´t the software industry limiting itself by not moving in that direction?

I´m not talking about "code secrets" when I´m suggesting more specialization and clear responsibilities. I´m talking about not actively spreading opening black boxes.

And if you can´t imagine "confining someone to small parts" of a whole, then think about your neurologist or chiropractor. They are specialists confined to a small part of the body´s whole.

Yes, sure, I can see the difference between our pretty constant body and ever changing software. Yes, I also think, different medical disciplins should work more closely together as it´s done in modern hospitals.

But I also know that medical practice has started with generalists and has evolved to its current state over the course of several thousand years. So I think it´s fair to say, software development is in its infancy and should consider the evolution of more established and older industries.

Also: I´m not against communication within a team. No, I´m all for communication! But I´m against a certain form of implicit uncontrolled communication.

@Rajesh: 1. I understand that "the idea is that everyone is responsible for the project". And that´s of course true. But it´s true for any project. This is the essence of the term "team". But responsibility in general does entail any special division of work.

Although it sounds nice, truely responsible programmers communicate changes before they apply them, I doubt this is universal practice. Given the fast pace of software projects you´re describing, there simply is no time to wait for tomorrow´s stand up meeting. Whoever thinks he knows better how to do something will simply do it.

2. "Never be blocked" sounds very good. But "good feelings" don´t sound all too good to me. Limited knowledge (let alone naivity or even hypocricy) often generate "good feelings", but not good quality.

Also, please read my posting carefully: I´m not saying, nobody must touch other´s code. I´m saying: There should be clear responsibilities and non-owners should behave like guests and all changes by non-owners need to be reviewed by the owner. I urgency requires it, a guest might change another person´s code - but this should be kept to a minimum due to two main reasons: 1. The guest might not know enough about the technology he´s using. 2. The gues learns details purposedly kept hidden behind a carefully designed interface.

Also: Please explain to me, why other industries don´t have a problem with specialization and clear responsibilities? Why does it work in lean car manufacturing all over the world?

3. "Specialization of developers is contraproductive" is a claim not proven, not even by the text you´re citing. Likewise - I have to admit - my claim also hasn´t been proven. Why haven´t you´re and my claim not been proven: because empirical studies in software development are scarce.

By the way: Heinlein´s view of what a human being should be able to do seems quite naive. Also he does not recognize that being a human in itself already is a specialization. In addition Heinlein neglects how far specialization has carried insects compared to humans and what the scenarios for a post-human world are.

Maybe I should answer Heinlein like this: Generalization is for settlers conquering a new world.

4. I´m not saying "quality" is primarily determined by "functional correctness". Right to the contrary!

6. Please explain the connection between your "knowledge of implementation details should be maximized" and the common architectural recommendations of black box thinking and loose coupling and information hiding?

-Ralf

@Jay: You´re right! I believe that someone needs to have a pretty clear vision of what a software should do, how it should look like. That´s the essence of the term "plan". Planning is necessary. It´s the basis for any civilization. But: Planning is not divination.

Although there needs to be someone with a vision who leads a team, he and the team must not stubbornly cling to a plan. Adaption is necessary over time. Agility is necessary. But agility does not mean absence of planning.

If there´s noone with some kind of plan in his head, then everything is just reaction to contingencies.

What do you mean by "high cost". "High" is a subjective measure. Handing over work is the norm in any other industry. So why should it not work for software development? Also: What´s needed to be handed over? Not explanations of whole implementations, but just contracts. Black boxes are controlled/used thru clearly defined interfaces.

So instead of incurring high costs for every (!) developer by having him to memorize as many details as possible from every corner of a software project, I actually am suggesting lowering cognitive load on the average developer. Like you don´t want to know about the details of a spreadsheet implementation, why should you know about the details of a, say, security component? You´re not the security specialist, so you should not care. Focus on your area of expertise.

Watching teams who work component oriented and using contract first design is surprising: First team members feel insecure because they don´t have control over everything. Code is hidden from them. But then... they change! The learn to like focussing on certain areas of code. They learn to feel the relieve this brings. They learn to feel the strength they regain by not needing to keep the full complexity of a whole implementation in the back of their heads. Have you watched a team like this? No? But I have!

Mind you: I´m not talking about penning up developers and feeding them thru a cat clap. No, developers should converse at the espresso machine, they should seek help from others. But they should not be responsible for all of the code! For one simple reason: Because they cannot become comfortable with all of the code because they cannot be experts in all of the necessary technologies.

Specialists better know their tools. And if I assign a security specialist to a security component, then he better uses his hammer. Why not? But if a security specialist is supposed to maintain database code... then his security hammer is not productive. So: Don´t let security specialists do data base programming. It´s that simple.

Of course specialists should optimize for their own area! That´s their purpose. How can a "generalized specialist" (or a jack-of-all-trades) optimize anything not in his domain of specialization? He cannot! Thus lacks the quality of the whole product.

Of course specialists need to be kept on track. But not so much by their peers, rather a lead is necessary who reviews code with specialists. Who ensures they don´t drift off into some ivory tower. Software also is about leadership. Groups (of a certain size) and complex undertakings need a leader.

Learning from each other: great!!!! Looking beyond ones area of specialization: great!!! But don´t think just from this and some good will springs quality.

-Ralf

Ralf,

Well, you certainly raise some interesting points, many of which I would disagree with when taking a more pragmatic approach. The principles of Agile development are principles, not absolutes. I have been on teams where the approach of "code silos" has been used with the justification that only the "experts" should touch the code. What I saw result was three things:
1. A lack of team cohesion. There was not a sense of teamwork or cooperation. This can have effects on many aspects of the program and organization.
2. Uneven work load. If one poor soul is burdened with disproportional responsibility of the system because they are the only expert, they can be overwhelmed and jeopordize the success of the entire project.
3. Failure to grow the organization. If a process continues to isolate individuals from other aspects of the system, the ability of those individuals to contribute to the project as well as their ability to contribute to future projects diminishes. If we take the argument that this industry in continually evolving, how do we help people to grow into new technologies if we isolate them to a single discipline.

On the other hand, when I worked on a team that employed agile methods (principles) I experienced a sharp contrast in behaviors, teamwork and job satisfaction than when working in silos. There are several observations I have about this.
1. Team cohesion improved. There was a reduction in the attitude "that's not my problem" and an increase in "what can we all do to make this happen."
2. Project success increased. With CCO we reduced the probability that one person was critical path and no one got burned out because they were overloaded. This also lead to an improvment in team cohesion.
3. Technical growth as a team. As a result of pair programming and CCO, the technical expertise of the entire team increased.
4. Project understanding increased. As people had more exposure to various aspects of the system, their understanding of the entire system increased and their ability to understand the impact of new or changed functionality increased.
5. Structure of code improved. It was interesting to see how people changed their coding standards when they knew someone else could be looking at or changing the code. They were more likely to follow coding standards and less likely to take "short cuts".

I don't think anyone could disagree that there is a need for individuals to have depth in certain areas and that it is unrealistic to expect everyone to be equally deep in all topics. But, through the "cross-pollenating" that occurs through pair-programming and CCO, the entire team can improve and thus be more valuable to the organization and to the project. When using other Agile process, there are checks and balances that help to ensure that when someone who is not an expert works in the code, that the code maintains its integrity. Indeed, good Agile process managment helps to ensure that there is always someone "more familiar" with the code working with someone who is "less familiar" with the code.

I feel it is too simplistic to take either extreme that everyone has to be an expert and only work on their piece or that everyone has to be an expert in everything. Reality indicates that for most projects it is some combination of both. I think the selection of which methodology to use really is dependent on the goals of the organization, project management capabilities, etc. I think it is dangerous to claim one is better than the other without taking all these things into account. Certainly, your argument that effectiveness requires understanding is valid and that expecting everyone to have the same level of expertise is unrealistic. I also think that to completely negate the benefits of CCO because of what appears to be a misunderstanding of how it can be effectively implemented is irresponsible.

It appears to me that the underlying issues are more rooted in project management than in development. The real question is "How do I mitigate risk and ensure progress." The Agile principles are a way to do this that, I feel, are easier to deploy and manage thn that of traditional project management principles. If there is a project manager that can get the job done with a bunch of experts, then they don't need Agile methods. Statistically, this has not been the case, thus the emergence of Agile processes.

Thanks for a great discussion.

-BJB

@BJB: Thanks a lot for your thoughful reply! I agree with most you´re saying.

The concerns you raised are very valid! Lack of team cohesion, uneven workload, difficulty to grow the organization. These dangers must be countered.

However, I doubt CCO is the only remedie, because CCO opens up a new danger: decrease in quality of code due to ever shallower skills compared to the available options, "mental overload" due to the goal of understanding whole systems which become ever more complex.

So the question is: What´s the best way to avoid all these dangers you and I am pointing at?

I agree with you "the underlying issues are more rooted in project management than in development". And I also agree with "Agile principles are a way to do this". Agile principles are important to software development.

But also the Agile movement has its roots somewhere in the past. By the very nature of any "ideologogy" this means, the Agile movement, too, has a tendency to "petrification".

So maybe the Agile movement needs to become a little more agile itself (meta-agility? ;-) in order to react to an ever changing world? XP is a child of the late 1990s and might need to adapt a bit. Once XP start to set anything in stone, it betrays its original claim, I´d say.

By the way: Simple calculation will show I cannot have strayed that far from the "true lore of XP" :-)

Any decent project will consist of nc components where nc is much larger than the number of available developers nd: nc >> nd.

That means, out of sheere necessity each developer whould be responsible far more than just 1 or 2 components. The calculation could even be as simple as: Each developer is responsible for 100/np percent of the code. I´d say, that´s not so bad, the "code silos" then mostly are not that small.

And it´s also true for smaller teams that the number of relevant areas of technologies nt (or areas of potential specialization) is larger than np or even np*2 (if we assume, each dev. could be specialist for two technologies): nt >> np*2.

So the issue I wanted to raise is: How to cope with nt>>np*2 and at the same time ever more complex software systems and the need for higher quality software?

-Ralf

[quote]
So the issue I wanted to raise is: How to cope with nt>>np*2 and at the same time ever more complex software systems and the need for higher quality software?
[/quote]

Perhaps I'm missing something, but we'd have to first agree on what quality is. Are you referring to code quality, process quality, or some other "quality" aspect?

I am going to assume you are referring to "code quality," but can you refine what aspect of "code quality" is imperative in achieving "higher quality software?" Quality implies something measurable, either quantitatively or qualitatively.. essentially a testable (whether automatically or manually) feature or featureset. Is there a code aspect that is given higher demands than ever before which is not testable or verifiable -- regardless of technology or problem-solution pair the technology aims to address?

The problem with "quality" goalposts is it never approaches what is appropriate for all projects. Like choosing the right tool for the job, you have to choose the right thing to measure as you go along and as you finish. What you build may not match the print, from feature to feature, but as long as it fits the overall problem -- getting from point A to point B, in time T, using less than resource R with P or greater predictability, where's the problem with the Q-quality?

The benifit I see from the combination of CCO and pair-programming is that your typical peer review process happens immediately, as needed, instead of as afterthought -- subject to schedule constraints and whims. When your development process does not accomodate a peer review process as seamlessly and as painlessly as CCO can accomplish, you run a high risk of never performing an adequate, appropriate, timely review.

Functional and unit tests ensure you meet certain customer constraints, but it's the peer review process that ensures you meet the more subjective design guidelines and design quality metrics... the stuff that is currently less testable than those black box features -- the inevitible future-proofing, readability, consistency, redundancy, side-effect (intentional vs unintentional) problem-solving, etc.. that is where CCO is a clearer winner than current alternatives.

@Justin: I´m talking about code quality. And I think it´s essential to achieve higher overall software quality.

What do I mean by code quality? Well, I´m not so much concerned with correctness here. That´s a given. I´m concerned with choosing the best tool/technology for a job and using this choice in the best way possible. I´m not talking about "just good enough", I mean "using it like an expert" which means "using it appropriately".

To use a tool/technology really appropriately (which can mean, you neglect certain features) means, you know exactly what you´re doing. You know all your options and choose the ones to apply "wisely". It does not mean "I know this tool and use it just like I can." Because if tools/technologies are just used like some guy knows them to use, then tools/technologies are not exploited. It´s like using Word like you used Word 2 versions ago - and complain about a lacking feature, which is already present, but you don´t know of.

As I have stated clearly: I strongly believe today´s tools/technologies have become so complex/complicated that no one developer can master more than maybe 2 or 3 of them. But more than 2 or 3 of them are necessary in any project.

So what do you do? In order to apply those tools/technologies appropriately (as defined above) you need specialists.

Specialists on the other hand should not dabble with code lying not in their realm of specialization. I won´t manufacture shoes nor would I bake bread nor would I build a house. And I´m very content being a software specialist in a world of specialization. The times of settlers and cowboys are over.

I agree with you, that code needs to be reviewed often/constantly. If you choose pair-programming for that, that´s fine with me. But pair-programming is not CCO. Also CCO does not require pair-programming (although maybe CCO is achieved more easily then).

Also CCO is not equal to code review in general. And code review does not need CCO.

So you say, CCO is the winner when it comes to "future proofing, readability, consistency, (avoidance of) redundancy and side-effects"? Well, that sounds like CCO being the holy grail to me ;-)

Future proofing and avoidance of redundancy and side effects for me are issues that should be planned and not left to "it just happens". And if you say, you can´t plan all that, then I reply: Well, a plan needs feedback, so of course there needs to be review and testing. Planning is not divination. Planning is just formulating an intention and a goal.

Let me say it again: I´m a great fan of constant testing and continuous integration. Openness for refactoring and iterations and short release cycles are great. Pair programming... well, if you like it ;-)

But CCO I think is outright anachronistic - even if you probably will call my position anachronistic because I´m using terms like "plan" and "clear responsibility".

-Ralf

PingBack from http://exceptionz.wordpress.com/2006/04/07/misconceptions-of-extreme-programming/

There are some good comments on this post. Really interesting viewpoints that is worth the read.