Simplest Thing Reply From Ron Jeffries

By intentionally creating a thing that is flimsy and barely functional for your needs (much less someone else's), you have intentionally created an artifact which is so handcrafted and rudimentary that it will probably be unsuitable when examined as a candidate for reuse or other repurposing.

Not guilty. Simple doesn't mean flimsy. In ExtremeProgramming, every object must have and pass all its UnitTests, and the entire system must pass its AcceptanceTests.

It's true, though, that our objects are barely functional, in that they do just what they have to do and no more.

We freely state that reuse external to our project is not an project value, for two reasons:

our job is to do our project, not to spend the customer's money on some future project, and
reuse rarely happens anyway.

Reuse internal to our project happens as part of the evolution of simple objects to more generally useful ones. When I need some new object, I write the simplest object that can do what I need. Maybe it supports a collection of Rates by Date. Someday in the future, someone else needs a similar object. If she finds mine, she enhances it. She probably asks me to pair with her while she does it. If she doesn't find mine right away, no problem. Since we RefactorMercilessly, we'll combine the two objects when we discover the duplication. This will happen quickly because we ValueCommunication? and practice PairProgramming, so everyone knows what everyone is doing.

But the YouArentGonnaNeedIt philosophy would seem to imply that your lack of time and resources absolves you of responsibility for creating a house-of-cards that will probably collapse in the next breeze.

Again, not guilty. Simplicity isn't a house of cards. ExtremeProgramming rests on the firm support of UnitTests and AcceptanceTests. Everything we make is solid. It's just simple. The rule is Simplest and Could Possibly Work. By the time you release, it's simple and does work.

When things change and requirements do emerge, we RefactorMercilessly to ensure that there is no duplication in the system.

"Also, a little extra work would have gone a long way towards preventing consignment of rigid, simplistic code or designs to the scrap heap.

DoTheSimplestThingThatCouldPossiblyWork does require extra work. You have to make the code right, which entails removing redundant methods or classes, and so on. The point is to use a simple solution, implemented appropriately, not a complex solution.

That said, in ExtremeProgramming we do not hesitate to throw things away when they have outlived their usefulness. In Smalltalk, and on our small team (10 developers), we can easily replace entire classes and all their uses. This week, one of the developers replaced a central component of the system's organizational classes, called BinDefinition?. It pissed him off, and he fixed it. Took him three hours to do it, and an hour of review. The system is better, faster, more reliable, easier to understand for it.

Consequently, YouArentGonnaNeedIt is rarely a good solution to project pressure (in my most humble opinion).

We don't do YouArentGonnaNeedIt in response to pressure. It is an inbuilt part of why we can go fast: we do what we need, and avoid what we don't need. We do today's work today, leave tomorrow's to tomorrow. We engage the customer's problem, not our own imaginings about what would be potentially useful to code.

Resistance to those project pressures is usually the best, and most difficult, course of action.

Seriously, resistance isn't good for the soul of the project. Reaching agreement with the customer on what will be done is. This has two aspects:

Know what has to be done. We have stories, with estimates for how long each one will take, divided into iterations.
Know how long they will take. One way we make sure we know is that we don't invest in what we don't need. Keeps us from running down a rathole searching for some future benefit while the customer contemplates alternative solutions to the real problem. -- RonJeffries

Seriously, resistance isn't good for the soul of the project.

(see also: WuWei)