Extreme Programming

for RuBoard

As with refactoring, no discussion of building software in small pieces would be complete without broaching Extreme Programming (XP), the recent software development methodology espoused by Kent Beck and others. Because short release cycles and iterative development are key tenets of the methodology, it's natural that we should delve into XP a bit here.

XP is a relatively new approach to software development that attempts to capture, in a formal methodology, the way that many developers already work. It emphasizes flexibility during the development process in lieu of rigid design and analysis. It has been described as a distillation of the way that programmers behave "in the wild," and I suspect that that's probably true. Most programmers probably don't adhere to rigid design methodologies or analysis. This is especially true of hackersdevelopers without formal training or the desire to follow what training they have. In this sense, XP is the hacker's methodology. It codifies what hackers have been doing for years .

According to the XP methodology, cost, time, quality, and scope are the four key control variables in software projects, and if any three of these change during the project, the fourth can be adjusted to compensate for them. Scope is viewed as the most useful of the four variables. If cost, time, or quality changes during the project, scope can be adjusted to offset them. For example, if the project deadline is suddenly moved up from 12 months to 6 months, the scope of the project can be narrowed commensurately. As long as at least one of the four variables remains in control of the programmers doing the work, the project should be do-able. When all four variables are controlled by entities outside the development team, you typically end up getting bad software late. [21] In this situation, your chances of project success are extremely low.

[21] Beck, Kent. Extreme Programming Explained: Embrace Change . Reading, MA: Addison- Wesley, 2000. Page 15.

This said, there's no simple relationship between the four variables. For example, increasing the resources (cost) on a project does not necessarily ensure that you can also increase scope. Some things have sequential, time-based, or otherwise complex relationships that are beyond simple resource management. As the old saying goes, "Nine women can't make a baby in one month."

Quality is a poor control variable because the gains you can make by sacrificing quality are short term at best. Exchanging quality for producing software in less time is a Faustian bargain that has doomed more than one software company. Sacrificing internal quality (defined by programmers) while hoping that it won't affect external quality (defined by customers) is merely wishful thinking. Eventually, it will catch up with you. Either the software will be too expensive to maintain, or it will never be able to reach a competitive level of external quality. [22] Don't do it unless you like laying awake at night or changing jobs.

[22] Ibid. Page 18.

The scope "safety valve" in XP operates based upon two assumptions: One, because you'll get lots of practice and feedback making estimates, the commitments you make regarding project scope will be generally accurate. And two, because tasks are prioritized in order of importance to the user , if a task has to be dropped because of a scope adjustment, it will be of lesser importance than the tasks that were not dropped.

XP subscribes to the notion that it's better to do a simple thing today and pay a little more tomorrow to change it than to pay a little more today for functionality that may not be used tomorrow. When such functionality is needed down the road, it can simply be refactored into the system.

Testing is an integral component of XP. In fact, tests determine project completeness: If tests fail to run, the project isn't done. If they do run, the project is complete.

Development is done iteratively, in small pieces in XP. Each time new functionality is added, it is tested via an automated test before proceeding with the next feature. According to the XP methodology, functionality for which no tests exist does not itself exist. The XP development cycle is change-test, change-test, change-test.

All production-level code is done with two developers at one computera concept XP refers to as pair programming. The two developers review one another's code, solve problems together, and generally function as one entity in getting the work of software development done. Pairs are not permanent fixtures. You may participate in one pair in the morning and another in the afternoon. With good communication and adherence to XP's other values, you are able to be more productive as a member of a pair than you would be individually.

XP embraces the notion of constant integration. Each time a new feature is added, it is integrated into the main build of the application. This helps avoid breaking other parts of the system "at a distance," and helps detect integration bugs early.

XP teams tend to become "intellectual nomads." [23] They have to be prepared to pull up stakes and follow the caravan at a moment's notice. The principle that software design should be more or less static once construction begins is thrown completely out the window. XPers adapt to whatever the customer wants, as long as it's humanly possible.

[23] Ibid. Page 42.

I think that about sums up what XP is and what its major tenets are. What do I think of XP? Like most software methodologies, there's good and bad in XP. Obviously, it works for Kent Beck and others. However, I don't think it would work for the majority of developers out there, nor do I think all its tenets are even good ideas. Let me explain.

When I ask myself what's wrong with XP, the first thing that jumps to mind is pair programming. I find the very notion of this a bit loopy. When I code, I need to concentrate. Interruptions, distractions, and most especially someone sitting right next to me, tend to interfere with my ability to concentrate, as they would, I think, most anyone . Coding is about thinkingthinking deeply. You can't do that when someone else is typing 18 inches from you or talking incessantly. Interruptions and distractions lead to shallow designs, poor code, and bugs.

Also, I'd think employers would have a problem with paying two highly trained software engineers to do the work of one (usually, they like it the other way around). The XP camp may respond that pairs are at least twice as productive as a single programmer, and therefore the difference is a wash, but I'd have to doubt this. Like most coders, I think best when I'm at a keyboard typing. I need to visualize what I'm thinking to delve into it deeply. Working through it on my computer is the most expedient way to do this. There's no way I could be as productive with someone else working immediately next to me, and management would have a legitimate complaint that I wasn't getting as much work done because of it.

I'll concede that I've never tried this particular tenet of XP specifically for the purpose of evaluating its fitness as a development technique, so I could be wrong. Moreover, I'd confess that I've solved more than one hairy coding problem by having someone sit at a computer with me and work through the obvious and not-so-obvious elements of it together. I know collaboration of this type can work. What I have a hard time swallowing is that it could work day in and day out, in lieu of the typical one-on-one interaction between the coder and the computer that has been the norm practically since the dawn of computers.

Another key flaw I see in XP is the deemphasis on up-front design. I think this is a mistake. We need to know all we can know up-front. Sure there are things we can't know, things that would be a waste of time even to attempt to know up-front, but jumping into the coding phase without a clue as to what we're to do is a recipe for disaster. It's like leaving on a cross-country trip without a map or a destination: You might come up with a destination along the way, and you might reach it, but you'll surely spend a lot of time lost, and you'll make it very hard for people to follow you or anticipate your arrival.

As a project manager, if an app is going to need a particular business object, I need to know that as soon as possible so that I can task someone with creating it before the other pieces of the app that use it are complete. If we're creating a new transformation service that uses XML to move data, I need to know that soon so I can have someone get to work on some XML style sheets quickly, before the portion of the app that uses them needs them. Scheduling, particularly elements that have dependencies on other elements, requires up-front design and careful planning. If you don't schedule your resources according to your needs, you may not reach your goals. It's that simple.

There's a reason projects have been managed, for time immemorial, by planning them out as much as possible to begin with. It's because the strategy works. Abandoning the tried-and-true in favor of a seat-of-the-pants approach to project management is lunacy, and I have a very hard time believing that it could work consistently.

But the real problem with XP's deemphasis on design isn't the uncertainty of taking a trip without a road map, nor is it the fact that meaningful scheduling depends on detailed design. It is that such a practice encourages programmers to abandon application design altogether. I wouldn't think that overdesign or overplanning is a big problem with most coders. Perhaps this was a problem with an isolated project here or there that the proponents of XP could name , but not with programmers in general. No, the problem with most coders is that they do not analyze, design, or plan enough. In After the Gold Rush , Steve McConnell [24] estimates that as much as 75% of the developers building software today do little or no design work before they begin coding. By sanctioning designless programming, XP is encouraging them to continue on in their sinful ways. This can only lead to poorly conceived software and failed projects. It is a world where estimates mean nothing and where design is an afterthought, not the guiding principle that keeps the software on track, a framework on which the system is built.

[24] McConnell, Steve. After the Gold Rush . Redmond, WA: Microsoft Press, 1999. Page 69.

Code First, Think Later

In After the Gold Rush , McConnell [25] refers to this approach to software creation as " code-and-fix " development. I like to call it "code first, think later" development. Code is created rapidly , but, because the quality is low and the overall strategy is not well thought out, it must be fixed repeatedly after the fact. Often, and certainly by the end of a project, more time is spent fixing code than writing it, with deep-seated bugs tending to snowball right around the time the software ships. Writing code without properly analyzing the problems to be solved courts disaster because it fails to acknowledge the obviousthat writing quality software is hard, and, like most complex undertakings, requires careful analysis and planning to be carried out successfully.

[25] Ibid. Page 11.

You have to remember that the fact that you're making progress on a project doesn't mean that you're making sufficient progress. If you spend the first 10 days of a 90-day project jumping straight into the construction phase, but only move 5 days closer to completion, you've actually lost time. Now you have to pick up the pace just to catch up. The construction of the application tends to be the easy part, the part that goes fastest . Properly analyzing and designing a system is more cerebral, and often requires a significant time investment. If you wait to the last minute to analyze the problem and to design a system to solve it, you'll likely find yourself knee-deep in a swamp full of alligator- sized defects, no closer to having a shippable product than when you started. As McConnell says, "quick movement off the starting line doesn't necessarily translate to quick movement toward the finish line." [26]

[26] Ibid. Page 11.

And the problems with underanalyzed and underdesigned systems go beyond simple software defects. Sometimes the code isn't buggy ; it's just that it doesn't meet the needs of the customer. In other words, the building is square and the roof doesn't leak, but it's the wrong building. This sort of misstep is usually the result of poor planning, a lack of design, or a lack of user involvement with a project. The first two causes are symptoms of code first, think later developmenta practice the industry has known to be ineffective for more than 20 years now.

Proponents of code first, think later like to romanticize the notion of programmers eagerly diving into the coding phase on a whim, like so many paratroopers jumping to their commando targets at a moment's notice. Developers who'd rather plan the assault before making it are branded as dawdling technocrats. There's a certain smugness associated with being first and foremost a code warrior , a soldier in the great crusade to liberate the minds of staunchy engineer-types the -world over.

But this idea is a fallacy. Omitting the analysis and design phases of software creation leads inevitably to code "thrashing"an endless cycle of debugging, fixing, and testing from which few projects ever really recover, even those that eventually ship. Coding is fun, but code first, think later relegates much of the time spent "coding" merely to fixing bugs introduced in earlier coding sessionsnot the typical code warrior's idea of exhilaration. The cycle is a vicious one and has doomed many a project.

The ironic thing about this style of development is that its participants usually spend as much time planning and designing as those who take a more systematic approach to software creation. [27] It's just that they do so out of sequence and usually when it will do the least amount of good. The cost of changing software increases exponentially over time, so analyzing and designing a problem upstreamthat is, working out the bugs in how you think about the problemcan yield dividends downstream that aren't otherwise attainable.

[27] Ibid. Page 13.

McConnell compares the code-and-fix approach to software development to fool's goldit is attractive to unsophisticated organizations because it allows the project to begin showing signs of progress immediately and because it requires little training. The problems with the approach aren't immediately obvious and are repeatedly missed by the very organizations suffering from them. Any old hack can throw together code that compiles and appears to run correctly, especially with today's tools. It takes an engineer to carefully analyze, plan, and conceptualize something as intricate as a complex software system before building it.

Redemption

These things aside, XP does have several redeeming qualities. First, I think the concept of iterative development and short release cycles is a good one. Making small changes is, as I've said, one of the primary keys to successful projects. Also, I think XPs four values (courage, communication, simplicity, and feedback) are good ones and make sense independent of XP itself. Of course you need courage to build software in this day and age. And as Beck [28] so insightfully points out, courage without the other values (communication, simplicity, and feedback) is merely hacking.

[28] Beck, Kent. Extreme Programming Explained: Embrace Change . Reading, MA: Addison- Wesley, 2000. Page 34.

Refactoring belongs in any serious software development methodology, so XP's emphasis on it is a good thing. Testing is similarly important. That XP places such emphasis on testing is a tribute to its proponents' depth of experience. Expert developers know how crucial good testing is. The really great developers get a little jolt of confidence every time they hit the test button. This might seem counterintuitive. Perhaps you'd think that expert developers are so good that they don't need to test their code, but the opposite is true. The more experience and skill you develop as a coder, the more you realize how little you know, how flawed your brain can be at times, and how nice tools are that can test your work for you.

The bottom line is that there are good things and bad things in XP. Because I find some of its tenets impractical , I don't expect it to displace more established development methodologies anytime soon. And I don't believe there will ever be a day when it is more common to see two programmers at a computer than one. Moreover, I do not think that a lack of emphasis on up-front design and analysis can be successful over the long haul with the majority of developers. Yes, I could believe that expert developers could pull it off on occasion, but the average developer needs to design and plan up-front, and XP fails to recognize this.

for RuBoard


The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
ISBN: 201700468
EAN: N/A
Year: 2005
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net