Extreme Thinking

I was responding to the following statement on a mailing list: "The fact is that XP [ExtremeProgramming] involves coding without aforethought."

I'm sorry I haven't been more clear in communicating on this point. I'll try to explain the technical heartbeat of XP again-

During iteration planning, all the work for the iteration is broken down into tasks. Programmers sign up for tasks, then estimate them in ideal programming days. Tasks more than 3-4 days are further subdivided, because otherwise the estimates are too risky.

So, in implementing a task, the programmer just starts coding without aforethought. Well, not quite. First, the programmer finds a partner. They may have a particular partner in mind, because of specialized knowledge or the need for training, or they might just shout out "who has a couple of hours?"

Now they can jump right in without aforethought. Not quite. First they have to discuss the task with the customer. They might pull out CRC cards, or ask for functional test cases, or supporting documentation.

Okay, discussion is over, now the "no aforethought" can begin. But first, they have to write the first test case. Of course, in writing the first test case, they have to precisely explore both the expected behavior of the test case, and how it will be reflected in the code. Is it a new method? A new object? How does it fit with the other objects and messages in the system? Should the existing interfaces be refactored so the new interface fits in more smoothly, symmetrically, communicatively? If so, they refactor first. Then they write the test case. And run it, just in case.

Now it's hacking time. But first a little review of the existing implementation. The partners imagine the implementation of the new test case. If it is ugly or involves duplicate code, the try to imagine how to refactor the existing implementation so the new implementation fits in nicely. If they can imagine such a refactoring, they do it.

Okay, now it really is hacking time. They make the test case run. No more of this aforethought business. Hack hack hack. This phase usually takes 1-5 minutes. While they are slinging code around with wild abandon, they may imagine new test cases, or possible refactorings. If so, they note them on a to do list.

Now they reflect on what they did. If they discovered a simplification while they were "no aforethoughting", they refactor.

This process continues until all the test cases they can imagine all run. Then they integrate their changes with the rest of the system and run the global unit test suite. When it runs at 100% (usually the first time), they release their changes.

I never think more, both before and after coding, than when I am in the flow of this process. So I'm not worried about accusations that XP involves not thinking. It certainly isn't true from my perspective. And people who have actually tried it agree.

KentBeck

Where does Thinking fit into ExtremeProgramming? I see afterthinking in Refactoring, but I don't see any beforethinking. --BetsyHanesPerry

I could answer that question several ways ...

Provocative. The ExtremeProgrammer is too busy learning to think.
Snide. What do you want to think for, it'll just screw up your code.
Serious. The kind of thinking I used to do before coding wasn't helpful. I would impute all sorts of requirements that weren't really there, and end up building something far too complicated.

The ExtremeProgrammer does BeforeThinking? in two ways. The first is figuring out what the next test case should be, thinking about the objects strictly in terms of their external protocol. The second is answering the question, "What is the simplest thing that could possibly work?" Sometimes you just make the test case work, sometimes you refactor first so you can easily make the test case work.

AfterThinking? comes in the form of 1) restructuring the system based on what it is telling you about how it wants to be structured and 2) filling in test cases suggested by the code.

There's a lot of thought going on, before and after, more than in any way I've ever programmed before. -- KentBeck

Sorry, I didn't mean to imply you weren't thinking, though I wouldn't have missed your riff on the subject for the world. Rather, I was commenting on your opening salvo, which says "LTCR, that's all there is to software." In other words, anything besides LTCR is superfluous. I've worked on projects where people coded without thinking, and the results didn't ship. Your described process guards against the Scylla of overthinking; it does not, in the original formulation, address the Charybdis of underthinking. It seems to me that your riff does a better job of navigating between the hazards. --BetsyHanesPerry

There's two types of not thinking. One good and one bad

1. You have design guides, coding style, coding standards, naming standards, and the compiler. This cuts down the amount of thinking to do in two ways:

The decisions about how to code make themselves, because of the standards you have. For example one of our standards is "Don't inline". Ok, it means we don't have to think about whether it would be better to inline.
When using other developers' interfaces, you don't have to think too hard. e.g., when I substantively use class ClassName, I know in this organization I need a header file called ClassName.hh - it's not className.hh or ClassNam.hh (thank the Buddha we don't use DOS). And I know that ClassName is a type, CLASS_NAME is a macro, firstNum is an object in local scope, myFirstNum is a member object, ourNextNum is a static member, and fsLowestNumber is my idea of a file static.

Consider also modifying your compiler to enforce the coding standards that you have, if the source is available.

1a. With UnitTests you don't have to think too hard when refactoring the code - the tests will tell you if you screw up.

2. The not thinking by those who deserve ParkingLotTherapy - more specifically those that write code without considering the consequences, or break all the rules, whether described above or otherwise (that guy who has 15 years C experience is a prime candidate)

-- NickBishop

ExtremeThinking can be used outside of Extreme Anything Else

When you are thinking in the extreme, you are in the wilds, you mentally engage the thought that comes to your mind, you give it a new mental handle, and take it somewhere it has not yet been.

Your engagement with the thought makes in your mind pictures, sounds, feelings and other associations and which lead you to other thoughts which you either relate or associate, and you may be able to associate words with them. Words have a strange power over out mental processes in that they have many branches and roots. Some of these are very strong, while others may be so weak as to be almost missed.

The weak or tiny branches or roots are what we grow in ExtremeThinking.

Just as clouds grow at their edges and boundaries, our thinking can grow by forming new MentalAcknowledgement?s. This can take form via YesNoMaybeSo?. ExtremeThinking gets its direction from the answer we get when we ThinkAboutIt.

--DonaldNoyes.ThinkingOutLoud.20130823