Duct Tape and Design: Applying Extreme Programming to System Administration
- What is XP?
- Extreme System Administration
- Caveat Admin
- Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Lately I've been reading a lot about extreme programming, often abbreviated XP (see http://www.extreme programming for more details). I like what I've been reading and I'd like to start using the ideas, but I'm a sys admin, not a developer. Do the ideas work in my domain? I think they do. In this article I'll lay out the basic tenets of XP, look at how the practices might fit into system administration, and discuss some possible problems.
XP seems to affect people rather strongly. They either love it or hate it. If you hate XP, don't stop reading here. I'm not advocating system administration Wild West style; then again, XP doesn't advocate cowboy coders either. There seem to be many ideas in XP that would do quite well in improving the work of many sys admins.
If you do like XP, you shouldn't stop here either.
What Is XP?
At the core of XP is the idea that there are some rules that lead to better, more efficient code. If these rules work better, why not do them all, all the time, all the way? XP isn't about hanging off a sheer rock wall—it's about doing things extremely well.
NOTE
The following terms come from the book Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999, ISBN 0-201-61641-6). See the "Resources" section for more places to look for information.
This central theme expresses itself in four core values:
Communication. If the developers and their customers aren't talking, problems will come up quickly and often.
Simplicity. "Do the simplest thing that could possibly work." The simpler your code, the less likely it is to break.
Feedback. Use frequent feedback to steer your work.
Courage. You need to have the courage to do what needs to be done. Inaction can be just as bad as the wrong action.
To keep the four values going, XP uses a set of twelve practices for the developer. Every programmer on the team should be using all of these practices throughout the life of the project. Keeping all of the knobs cranked is what XP is all about.
The planning game. One of the biggest complaints about XP is that it throws design out the window. This isn't really true. XP relies on a rough sketch of the overall shape with frequent short-term planning sessions to keep everything moving in the right direction.
Testing. Before any new code is written, a test should exist to ensure that the code works correctly. Before any project is declared complete, it has to meet all acceptance tests as well. The combination of constant (automated) unit testing and frequent acceptance testing helps to ensure a quality product.
Pair programming. Pairs of programmers write all the production code. One developer is responsible for the tactical end of things (getting compilable, correct code written). The other is the strategist and makes sure that the long-term impact of the code is in sync with what the project needs.
Refactoring. This is often termed "refactor mercilessly." Consistent cleaning and improvement of the code makes it easier to maintain and extend. Unit testing and pair programming help ensure that refactored code doesn't break existing functionality.
Simple design. Don't write functionality into a program where it isn't needed. Because you're refactoring code regularly (and because you unit-test everything all the time), adding functionality later is easier. When you find out you need something, you'll know just what to add.
Collective code ownership. Each member on the team should know enough about the system to make any needed changes, and should have the authority to do so.
Continuous integration. After each new bit of functionality is added by a pair of programmers, it should be tested and integrated back into the main tree. If everything is tested before it's integrated, you rarely need to worry about the system breaking. If integration happens often, no one is surprised by changes.
On-site customer. Having the customer right there allows minor course corrections to happen in near real-time. Without it, development is slowed while programmers wait for feedback.
Small releases. Releases should be as small as possible while still doing something valid. Many projects shoot for a two-week release cycle.
40-hour week. If you work too many hours for too many days, you'll burn out. Stay away from "death marches."
Coding standards. If everyone is using the same coding style, it's easier to refactor, the code is easier to understand, and it's easier to switch partners as you move along.
Metaphor. Everyone working on a project needs to understand how it all fits together.
This is a very short description of XP. To really understand it, you probably need to take a look at some of the sites listed down in the "Resources" section of this article. Hopefully, you've got enough information to look at XP through a sys admin's glasses.