XP Rule: don't spend more than a few minutes thinking about what the system is or how it might be done. With a partner, or alone if you must, write some sample code that makes your ideas real. Plan to throw it all away ... you are trying to move from your thought-world, which is fun but fuzzy, into the real world, which is where your answer must be found.
Years ago, concerned that such experiments might get turned into products at gunpoint, we joked about prototyping in a language that the company wouldn't dare ship a product in, like Smalltalk. :-) --DaveSmith
And as we speak, Texas is considering licensure for ProfessionalSoftwareEngineer(s). An interesting issue for consideration: would ExtremeProgramming as it eschews up front planning be considered a professional practice? Especially when the rest of the world thinks that proper software engineering requires diagrammatic work and lots of chin rubbing before writing a drop of code?
Do we have to act somber now? Is it still going to be fun?
I believe, based on considerable study, that XP projects can readily be certified under IsoNineThousand. Acting somber isn't necessary unless you write it into your rules. Fun is always problematical: often you have to make sure no one realizes you are having any.
In fact, XP does up front planning. We provide a CommitmentSchedule that has a better claim to correctness than the plans of most projects. We don't do a lot of chin rubbing, except on our own time.
Up front design in XP is done with SpikeSolution and similar experiments. These have a better record of actually showing you how to do things than all the paperwork of the DiagramMongers?.
And best of all, sounds like there will be some great contract opportunities in Texas, rescuing failed projects! --RonJeffries
Once you take their test. It looks like consultants and contractors would probably be affected more dramatically than corporate employees.
This is saying something about the relative costs and benefits of fantasy and experimentation. The idea that you can find experiments that are cheap yet useful. You can make them cheaper by forgetting about things like static type checking, scalability, prettiness of UI and speed if they are not relevant. (Any others?) Use an appropriate tool; the requirements here are not the same as the requirements for a production system, so different tools may be better.
Other ways to change the cost/benefit ratio of experiments? I expect there are several "common sense" ones.
See Also: RaceTheDamnedCar