(This article has been translated to Brazilian Portuguese by Luiz Esmiralha.)

In the early days of Extreme Programming, people praised it, and sometimes criticized it, as a "stake in the ground." XP, in the early days, was very clear about the right way to develop software. It took an extreme position and it was proud of that.

Since then, it's become popular to have a more, well, "world-weary" point of view. "Of course, there are many points of view." "Any process will work as you long as you have smart people." "XP is a nice ideal but in the real world we can't do (pair programming, test-driven development, continuous design, continuous integration, etc)."

The kind of point of view is very mature and wise and it sounds quite deep. It's also getting a little tiring. Yes, there are many processes. Yes, smart people can find a lot of ways to be successful. Yes, XP is inappropriate for some environments.

And yet, I miss the clear idealism of the early days. There was something satisfying about saying, "We know what works and we're not going to compromise about our best possible work. If the environment doesn't allow great work, we'll change the environment, not change our work."

I've run teams this way. They've been unusually successful. When you ditch the world-weary attitude, embrace XP, take it to the logical extreme, say "we will fix the problems in our environment, not work around them"... this stuff really works. No, scratch that. It doesn't just work: It works far better than anything else I've seen.

Inspired by my recent discussion of continuous integration, I'm going to take a stab at putting the stake back in the ground. Here's a fresh look at the original 12 XP practices, presented with a complete lack of humility, maturity, or world-weary wisdom. Think of it as the XP oath. Do these things, believe these things--even one is a good start--and you will be more successful. I guarantee it.

(Always read the fine print. While I guarantee that you will be more successful, I don't guarantee that you'll be successful. Maybe you'll graduate from abject failure to total failure, or something. Sadly, it takes more than brilliant programming to guarantee success. Besides, you have to do these things right and I have a hard enough time conveying that in person, let alone in 500 words. Basically, folks, you're on your own. Imagine an evil laugh here, and have a nice day.)

The Extreme Programmers' Oath (for an XP team to take together)

• We will always create schedules that reflect our best estimates. We will only estimate effort in chunks small enough to allow us estimate accurately. We will continuously verify our plan by stopping at predetermined, unchangeable time intervals and comparing reality to plan. When our plan differs from reality, we will change the plan. (Also known as... the planning game.)

• We will deliver real working software to real paying customers as soon as possible. We will find ways to deliver significant new value in less than three months. We will only include work in our schedule that our customers could recognize and understand. We will always deliver the highest-valued functionality first. (Also known as... small releases.)

• We will find a business expert who understands the customers' and users' point of view impeccably and we will find a way to make him or her available to sit with us full time. We will never guess about the customers' points of view. Instead, we will ask our expert whenever we have questions. (Also known as... on-site customer.)

• The latest code in our source code repository will always successfully build and pass tests. We will integrate our latest changes and commit them the repository every two to four hours. Our automated build will always be capable of building a deliverable package for us to give to paying customers, even if the total functionality doesn't yet warrant actually doing so. (Also known as... continuous integration.)

• We will minimize the cost of design changes by implementing the simplest--but not most simplistic--possible design for the features we have today. We will not add hooks or plug-in points for anticipated features if we are not programming them today. We will look for duplication and other design errors that increase the cost of unanticipated change and improve our design to remove these problems. (Also known as... simple design.)

• Whenever today's work reveals a flaw in our design, and whenever improving our design will allow us to finish today's work faster, we will change the code and improve the design. We will always make some improvement, even if it's as small as renaming an identifier, that leaves the design better today than it was yesterday. We will never allow the design quality to be worse today than it was yesterday. (Also known as... merciless refactoring.)

• We will test everything that could possibly break. We will have tests at the customer level as well as at the programmer level. We will write our tests before we write our code, possibly moments before. We will automate our tests and provide a binary "pass/fail" mechanism for evaluating the result. (Also known as... relentless testing.)

• We are jointly responsible for the quality of the codebase. When we see a problem that needs fixing, we will fix it, regardless of who originally wrote the code. When we have a feature that needs implementing, we will implement it, working in any part of the code necessary to achieve a quality result. We will not complain when somebody else makes a change to code we've written. (Also known as... collective code ownership.)

• We will work at the fastest pace that allows us to do our best, most productive work indefinitely. We will respond to emergencies and requests for more time compassionately and firmly, providing considered options for changing scope and resources rather than offering to work in a way that will decrease our quality or productivity. (Also known as... sustainable pace.)

• We recognize the difficulty of fulfilling this oath perfectly every day. We will provide support for every programmer by working in pairs. When we falter, we will rely on our partners to remind us of our duties. When our partners falter, we will support them with compassion and without judgement. Every day, we will help each other do the best, most productive work we are capable of doing today. We will avoid cliques and share new information by switching partners several times per day. (Also known as... pair programming.)

There's nuances. There's applicability issues. There's even ways to be more extreme. That's all true, and this is a stake in the ground. Start here.