The mistaken belief that IT projects succeed or fail because of low-level technical issues like data binding not working properly or the IDE being a bit kludgy. Many developers using ExtremeProgramming
live in a world where code is not a means to an end, but an end in itself. This might explain why the success rate of XP projects -- measured in business terms -- is as dismally poor as with most other methods, and why many XP developers are entirely unaware that their project actually has failed ("But we delivered it..."). Signs of a disproportionate FocusOnCode
- Changing the requirements to accommodate the architecture
- Blaming tools and technology for low productivity ("This would never have happened if we'd built it in Java"...)
- Being unable to tell you what the business goals of the project are without resorting to vague hand waving management babble ("To empower the knowledge workers", etc., etc.)
- Spending little or no time with the customer before writing code for a UserStory
- Failing to understand the context in which the system will be used (e.g., by watching how they currently do it)
- Listing >=90% technology issues in retrospectives
- Talking constantly about technology (just listen around you and see what the flavor of conversation tends to be)
- Having anything to do with SourceForge on the customer's time (you'd be amazed just how much OpenSource software is developed at the customer's expense and then shoehorned into the architecture to justify it)
The initial paragraph indicates that FocusOnCode
is a flaw with XP, yet many of the bullet-points have nothing to do with XP. Some, in fact, are contrary to XP principles (such as "Spending little or no time with the customer"). I agree that too many developers ignore business issues, but I see XP as one of the cures
for that, not the cause.
In any case, I see no evidence that XP is any worse that other methodologies in this respect. Programmers tend to FocusOnCode
no matter what the methodology is--that is their job.
Where are the statistics demonstrating that "the success rate of XP projects - measured in business terms - is as dismally poor as with most other methods"?
See also MythsAboutXp
Sounds like one very bitter StrawMan
argument. Anyway, the opening line is absolutely true, as anyone who's read PeopleWare
knows. The main underlying cause of project failure is inadequate management, not technical issues, nor developers doing open source work in company time!
As for projects that have been "delivered..." but still are business failures, surely that's a management problem too? If software is delivered on time (most isn't, you should be grateful!) yet fails to bring the mega-bucks in, then you can't blame XP, RUP, or anything in the development process at all.
Actually I'm going to change tack slightly and agree (slightly) with what is being alluded to. Basically, the power of software to increase profitability is overrated. All those late, over budget failures may have hidden the fact that even if they had been delivered within budget, the overall business benefit wouldn't be as great as the initial hyped up presentations suggested.
Where I take issue is to blame the developers and any specific methodology for this. That's like blaming the bus driver for the ugliness of the city they've driven you to! Many round here would agree that business managers know nothing of software development. You imply they know nothing of their own business, too! When Dilbert's (and my...) PointyHairedBoss
declared "every employee is a sales executive", maybe they should add "business strategist" to the list. What next? "Every employee is an executive car valeter"...
The bullet points seem to say "focuses on technology" in 4 different ways. Is that so surprising for people working in Information Technology
? The point of the division of labor is that the client is the expert on the Bolivian tin market, the hamster food trade, policy assurance insurance endowments or whatever it is they make money out of.
For ages everybody moaned software was late and expensive, now it seems business guys aren't happy even when it is delivered on time. Do you want the Moon On a Stick, too? -- BrianCooke
I think there's a valid point in all of this. XP does seem to attract people who have little or no interest in the business problems these projects are setting out to solve - believe me, I've worked with enough of them in the last 3 years. You can easily argue "but that's not XP's fault", but if the true meaning of any communication is the effect that it has, then the meaning of XP is FocusOnCode
. I do actually think that developers should take an active interest in understanding the business context and the overall goals of the project (assuming that the project has business goals, which is another good point being made here). I don't think it's asking too much at all. Developers need to be able to take a step back and look at the bigger picture.
A focus on code is
looking at the bigger picture. Code could well outlive any one project, and, at the end of the day, the business context is making money, anything
else is a means to an end. -- RichardCordova
"Failing to understand the context in which the system will be used (e.g., by watching how they currently do it)"
In most of the cases I have worked on, that is exactly what the customer is asking for - they want their existing workflow computerized. They don't want a better workflow from the software company, and will tear you a new orifice if you attempt to alter the existing flow. All they want is a system that removes the paper pieces from the flow, replacing them with online work orders, etc.
So if we watch what they currently do then we're compelled to reproduce it unchanged?
Exactly. The customer is looking for a specific solution, and does not want their process "improved"
I don't think it's asking too much at all. Developers need to be able to take a step back and look at the bigger picture.
Although I agree with this direction in principle, the general tone of blaming developers is hard to swallow. In my last project, a software workflow that do things exactly how they used to do things is all my customer wants. Unfortunately, even after 20-30 hours of meetings and discussion with the users doing the job, it turns out they still haven't described fully how they were doing their own job! Perhaps we just forgot to budget for the torture chamber to get the requirements out of them (a la Dilbert) :)
In short, when those whose job is to look at the "big picture" failed to see it, it is asking too much to have developers see it for them.
My alternative view. The above explains why it should be the developers job to understand the work environment. This is the flaw with the Waterfall approach, it is really impossible to solicit a list of every possible "requirement," all possible contingencies, and all work-around solutions used when the official approach fails. These things are not discovered until the software hits the field, therefore, get the initial software into the field quickly. --WayneMack
I would strongly suggest that sitting in meeting rooms with intended users is possibly the worst way to understand what they do :-) Go see it for yourselves. Indeed, why not have a go at it yourself? I could explain for days how to fly a Piper Cub, but until you've taken the wheel chances are you just won't understand what its really all about. Don't rely on the spoken word to communicate such rich and complex information.
Of course it is easier to take the wheel when there is a wheel to take. That is the only reason that xp emphasizes delivering a working system early.
This proto-antipattern certainly isn't unique to XP projects. It might even be less common in XP. But any project or team can fall victim to this, and it has a lot to do with the organization's maturity. Immature shops are always looking for the next SilverBullet
to solve the current set of problems. In one company, the difficulties encountered developing web applications in Java were going to be fixed by buying a set of WebSphere
-related tools and portal software from IBM. At least that was the view of some developers, but at least one developer at least who participated in the trial-run project was quick to note the risks of adopting all those new tools and technologies.