Extreme Tautologies

One of the strange features of ExtremeProgramming is that it uses phrases that no one could disagree with, but it takes them seriously, or interprets them in ways that generate surprising or even shocking conclusions. Here are some. Add your own.

Say things in your code that you know are right. Don't say things in your code that you don't know are right. -- This is closely related to "you aren't gonna need it" and "what is the simplest thing that could possibly work?".

Don't try to do more than you can do. -- Before we starting "pushing it", we must get good at delivering on what we know we can deliver. Development makes the story estimates (in ideal engineering weeks) and specifies how many weeks worth of stories they can deliver by a given date.

Business people make business decisions, technical people make technical decisions -- How often do the suits choose a programming tool, or developers decide which feature to implement first?

Test everything that could possibly break -- If you write code and you have the least doubt that it will work, write a unit test for it, preferably before you start coding. You end up coding faster in the short run, and producing more stable systems in the long run.

Get as many people making good decisions as possible -- This goes absolutely sideways to the "anointed architect" (or architecture team) model. But why wouldn't you want everybody making decisions at every level of abstraction, as long as they all played nicely together?

Estimate by estimating the parts in ideal engineering time, summing, multiplying by an ideal->calendar factor, and dividing by the number of developers -- What could be simpler? This rule seems to violate rules like BrooksLaw.

• Not if the calendar factor turns out to be a function of number of developers. As we go along, we measure the actual factor and use it, which would accommodate BrooksLaw, if in fact this is a violation. He didn't say starting with more people made you later, and in small variations, I would say it doesn't. --RonJeffries
• "CalendarMonths? = ManMonths? / NumberOfDevelopers?" is a common fallacy that does not violate "BrooksLaw," but it does violate other truths to be found in MythicalManMonth. You have to consider how "partitionable" the work is. Highly partitionable work can be done by a large number of people with little loss in productivity. However, unpartitionable work won't be done faster by a larger team. Like, even if you assign 9 women to the task, you can't produce a baby in one month. (On the other hand, doing the division and throwing in an approximated fudge factor consistently produces better results than doing nothing.)

Make your own commitments -- Nothing else is possible, because you are never committed to a "commitment" you didn't make. The developer who is going to be held to a date gets to say what the date is. The team that is going to be held to a date gets to say what the date is. If Business doesn't like the date, they can vary the functionality, or hire a better team.

Integrate often -- With the right tools and practices, this means several times a day. No code survives more than a couple of days away from the baseline.

Don't spend time on planning stuff that will never happen -- Make a broad overall plan showing why Business should pay for all this, then be prepared to deepen the parts of the plan that happen when they happen, and discard the parts that don't happen.

Don't make two guesses in a row -- Compounded risk kills projects. Most projects make hundreds of guesses in a row before getting any feedback.

Build what is most valuable to the person with the money -- Duh... Of course, you have to ask to find out what that is. And you may have to ask carefully. But you have to ask.