Is Xp Really The Simplest Thing That Could Possibly Work

The mathematician in me reasons as follows:

XP is the simplest thing that could possibly work. What happens when we leave out one of the XP programming practices? Well, we end up with something that is simpler than the simplest thing that could possibly work. Of course, that couldn't possibly work.

So, each programming practice and each prop prevents something going wrong. For most practices and props this has been sufficiently explained on these pages, but for a number of things I wonder why they are necessary:

Why does XP have both UnitTests and FunctionalTests? What's the fundamental difference between them?

UnitTests are written by programmers to assure themselves that their classes work and do not break any other classes. FunctionalTests are defined by the customers to assure themselves that the system does what they asked for. -- RonJeffries

Why couldn't it possibly work if you make an application object and write unit tests for it using xUnit? I believe I read somewhere on the XP pages that C3 uses a souped-up version of Kent Beck's testing framework for the functional tests. Why is this souping up necessary? What does it look like?

It's just a wrapper around the framework that displays a simple GUI that shows GREEN and 100% when all the tests have completed successfully, and RED and x% when some have failed. We made it so that we could see from across the room that the tests running on the integration machine are complete. -- RonJeffries

Why do we need both EngineeringTasks and UserStories?

A UserStory is written by the user to specify what the user wants. Engineering tasks are defined by the developers to specify what has to be done to make the system do what the user story asks. Usually there are several engineering tasks per user story. -- RonJeffries

Could the XP experts comment on this?

-- Martijn Meijering

Hello, Martijn.

XP isn't the simplest thing that could possibly work. We say that when you decide how to develop some feature, you should DO the simplest thing that could possibly work, i.e. take the shortest reasonable steps to the feature, not building in frills or features for the future.

But XP itself is definitely not the simplest thing that could possibly work. We think it's getting pretty close to the simplest thing that will probably work, but even that might be overstatement. In any case, XP isn't simple. It is very difficult to maintain the discipline to do it. I've addressed some specifics above. Please ask further if I haven't been clear. Thanks for your interest. -- RonJeffries

Simple doesn't have much to do with difficult to maintain the discipline to do it, I think. I find many simple things difficult to do.

The process is driven to be as simple as it can be and still produce the simplest system that meets the user stories, right? Since there are a few things still being done differently each time (CommitmentSchedule, I think), it would seem that the process is not as simple as it could be. What are the forces that drive the process to be simple? Speed? Communication? -- BillJamison

If XP is simplified in some way, and yet still works, this would prove the assertion false. And this has happened. "Simplest Defined Process that has worked for more than one person" might be more accurate, not as fun to say maybe, but more true. XP IMHO isn't even close to the simplest process that can work -- but it might be the first time, someone has extolled Simplicity as a Value in a Defined Process, that at least is taking us in the right direction. -- BillCaputo

By XP principles XP should not exist. Instead a methodology should arise as needed from a project. Anything else violates YouAintGonnaNeedIt (YAGNI) and TheSimpleThing?.

But you aren't gonna need a methodology to arise from a project, and wouldn't the simplest thing be to use one that already exists?

Use the same list of arguments XP uses against coding more than your current user story, using frameworks, etc. It's hard to imagine anything more BFUD than creating a methodology upfront without listening to a project as it is being created.

XP is a software development methodology. It's not appropriate to apply XP to itself, because XP is not software, and people aren't programmable.

I would not recommend creating a methodology on the fly unless you had experience with a wide variety of projects and people. Even then, I would start with an existing methodology. I've invented and adapted several methodologies and the results continue to surprise me. Creating a methodology is nothing like programming... not even close. (AlistairCockburn has discussed this - I thought in AlistairsScumTalk - but now I can't find the material.) -- JimLittle

If architecture on the fly works then why won't methodology on the fly work as well?

Use the same list of arguments XP uses against coding more than your current user story, using frameworks, etc. It's hard to imagine anything more BFUD than creating a methodology upfront without listening to a project as it is being created.

But XP wasn't created up front. They just did things that worked, stopped doing things that didn't, and then documented what worked.

How something was created isn't important.

I didn't say it was. I was refuting the statement that it was created up-front, because it wasn't.

When deciding to use it on a new project then it is BDUF.

Just like a framework may have been evolved, yet in XP you would not adopt it saying it should emerge as coding progresses.

I'm not any kind of authority on XP, but I don't think you're correct on that. As far as I know, nothing about XP precludes using existing frameworks that work. Otherwise C3 wouldn't have used GemStone, or for that matter, the Smalltalk class library.

There's nothing about a methodology that exempts it from the same evolutionary rules.

There's nothing about a methodology that binds it by the same evolutionary rules either. XP is a methodology for developing software, not other methodologies. But even so, XP abode by those rules because it was evolved.

It doesn't meet yagni or the simplest thing.

How does picking a methodology equate to big design, up-front or otherwise?

Clearly because it is not being generated by listening to the project. In XP you take one user story at a time and implement that. The methodology can be generated in the same way. It's BFUD when you do the opposite with code. It's the same for the methodology.

Nothing about XP precludes using existing frameworks that work. Otherwise C3 wouldn't have used GemStone, or for that matter, the Smalltalk class library.

What about YagniAndLogging?

YagniAndLogging questions whether you should put in logging before you really need it. Even if you take an extreme YouArentGonnaNeedIt position, that doesn't precude you from using a logging framework when the need does arise. That might be the SimplestThingThatCouldPossiblyWork.

XP looks a whole lot like it was built up as a series of the simplest things that could possibly work--there isn't a lot of cruft there that doesn't directly relate to the task at hand. At the end of the day it might not be that simple, but that's because it attempts to help with a hard problem. You see the same thing with software systems.

CategoryExtremeProgrammingDiscussion