The second XP value is simplicity. The XP coach asks the team, "What is the simplest thing that could possibly work?"
Simplicity is not easy. It is the hardest thing in the world not to look toward the things you'll need to implement tomorrow and next week and next month. But compulsively thinking ahead is listening to the fear of the exponential cost of change curve. Sometimes the coach has to gently remind the team that they are listening to their fears, "Maybe you're so much smarter than I am that you can make all this complicated dynamically balancing tree stuff work. I would naively assume a linear search would work."
Greg Hutchinson writes:
One person I was consulting to decided that we needed a general purpose dialog for displaying text. (OK, like we don't have enough already, but I digress.) We talked about the interface to this dialog and how it would work. The programmer decided that this dialog should be fairly smart and modify its size and the number of line breaks in the string based on the font size and other variables. I asked this person how many programmers needed this part currently. This programmer was the only one that needed it. I suggested that we make the dialog not so smart yet and make it work for their case (20 mins work), we could make the Class and the interface known and always make it smarter when a second case came along that needed those requirements. I couldn't convince this programmer, and they spent 2 days making this code. On the 3rd day even their requirements had changed and they no longer needed this part. 2 man days gone on a project that was already tight. However, please let me know if you could use this code. (Source: e-mail.)
XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway.
Simplicity and communication have a wonderful mutually supporting relationship. The more you communicate, the clearer you can see exactly what needs to be done and the more confidence you have about what really doesn't need to be done. The simpler your system is, the less you have to communicate about, which leads to more complete communication, especially if you can
simplify the system enough to require fewer programmers.
Feedback
The third value in XP is feedback. More coaching phrases are "Don't ask me, ask the system" and "Have you written a test case for that yet?" Concrete feedback about the current state of the
system is absolutely priceless. Optimism is an occupational hazard of programming. Feedback is the treatment.
Feedback works at different time scales. First, feedback works at the scale of minutes and days. The programmers write unit tests for all the logic in the system that could possibly break. The programmers have minute-by-minute concrete feedback about the state of their system. When customers write new "stories" (descriptions of features), the programmers immediately estimate them, so the customers have concrete feedback about the quality of their stories. The person who tracks progress watches the completion of the tasks to give the whole team feedback about
whether they are likely to finish everything they set out to do in a span of time.
Feedback also works at the scale of weeks and months. The customers and testers write
functional tests for all the stories (think "simplified use cases") implemented by the system. They have concrete feedback about the current state of their system. The customers review the
schedule every two or three weeks to see if the team's overall velocity matches the plan, and to adjust the plan. The system is put into production as soon as it makes sense, so the business can begin to "feel" what the system is like in action and discover how it can best be exploited.
Early production needs a little explanation. One of the strategies in the planning process is that the team puts the most valuable stories into production as soon as possible. This gives the
programmers concrete feedback about the quality of their decisions and development process that never comes until the rubber meets the road. Some programmers have never lived with a system in production. How can they possibly learn to do a better job?
Most projects seem to have exactly the opposite strategy. The thinking seems to go, "As soon as the system is in production, you can no longer make 'interesting' changes, so keep the system in development as long as possible."
This is exactly backwards. "In development" is a temporary state, one that the system will only be in for a small percentage of its life. Far better to give the system independent life, to make it stand and breathe on its own. You are going to have to live with supporting production and developing new functionality simultaneously. Better to get used to juggling production and development sooner rather than later.
Concrete feedback works together with communication and simplicity. The more feedback you have, the easier it is to communicate. If someone has an objection to some code you have written and they hand you a test case that breaks it, that is worth a thousand hours of discussion about design aesthetics. If you are communicating clearly, you will know what to test and measure to learn about the system. Simple systems are easier to test. Writing the test gives you a focus for just how simple the system can be—until the tests run, you're not done, and when the tests all run, you're done.
Courage
Within the context of the first three values—communication, simplicity, and feedback—it's time to go like hell. If you aren't going at absolutely your top speed, somebody else will be, and they will
eat your lunch.
Here is a story of courage in action. In the middle of iteration 8 of a 10-iteration engineering
schedule (25 weeks out of 30) of the first release of the first large XP project, the team discovered a fundamental flaw in the architecture. The functional test scores had been rising nicely, but then had flattened out far below where they needed to be. Fixing one defect caused another one. The problem was an architectural flaw.
(For the curious, the system computed payroll. Entitlements represented things the company owed employees. Deductions represented things the employees owed other people. Some people had been using negative Entitlements when they should have been using positive Deductions.)
The team did exactly the right thing. When they discovered that there was no way forward, they fixed the flaw. This immediately broke half of the tests that had been running. A few days of concentrated effort later, however, and the tests scores were again headed toward completion. That took courage.
Another courageous move is throwing code away. You know how sometimes you work all day on something, and it isn't going very well, and the machine crashes? And how the next morning you come in and in half an hour reconstruct all of the previous day's work but clean and simple this time?
Use this. If the end of the day is coming and the code is a little out of control, toss it. Maybe save the test cases, if you like the interface you've designed, but maybe not. Maybe just start over from scratch.
Or maybe you have three design alternatives. So, code a day's worth of each alternative, just to see how they feel. Toss the code and start over on the most promising design.
XP's design strategy resembles a hill-climbing algorithm. You get a simple design, then you make it a little more complex, then a little simpler, then a little more complex. The problem with hill-
climbing algorithms is reaching local optima, where no small change can improve the situation, but a large change could.
What is to say that you won't ever develop yourself into a corner? Courage. Every once in a while someone on the team will have a crazy idea that just might slash the complexity of the whole system. If they have courage, they'll try it out. It will work (sometimes). If they have courage, they'll put it into production. Now you're climbing a whole new hill.
If you don't have the first three values in place, courage by itself is just plain hacking (in the pejorative sense of that word). However, when combined with communication, simplicity, and concrete feedback, courage becomes extremely valuable.
Communication supports courage because it opens the possibility for more high-risk, high-reward experiments. "You don't like that? I hate that code. Let's see how much of it we can replace in an afternoon." Simplicity supports courage because you can afford to be much more courageous with
a simple system. You are much less likely to break it unknowingly. Courage supports simplicity because as soon as you see the possibility of simplifying the system you try it. Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see the tests turn green at the end (or not, in which case you throw the code away).