Focus On Code
Focus On CodeThe 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 include:
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.
-- JasonGorman
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. --PeteHardie 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.
EditText of this page
(last edited September 29, 2008)
or FindPage with title or text search