DoTheSimplestThingThatCouldPossiblyWork and don't win a PropellerBeanie.
XP is about developing software that returns business value to a customer. It can be used to build products or in-house applications. Whether it applies to pure R&D is open to question. Whether there is such a thing as pure R&D is also open to question, as people whose projects have suddenly gone unfunded might have cause to contemplate.
The XP rule, DoTheSimplestThingThatCouldPossiblyWork, and the C3 PropellerBeanie award for gratuitous complexity are not in any way directed against new solutions. They are reminders to avoid gratuitous complexity.
They are applied day to day, not year to year. Most software developers, day to day, are solving problems whose solution they do not know completely. In working out solutions, they go down false paths, they make mistakes. Sometimes they even spend days working on the wrong solution.
Sometimes they manage to work out a solution, but it is substantially more complex than one that would have served.
The rules are there to remind us to try the simpler solution first (YouArentGonnaNeedIt). If, as it often will, it solves the problem, the best thing to do is to make sure the simple solution is well-factored, well-encapsulated, and move on to the next problem.
The rules say nothing against new ideas. They say that whatever ideas you have, try the simplest one first, and don't put in something that is more than you need for the current problem.
It is my belief that the discussion below is predicated on a misunderstanding, perhaps accidental, of what XP says, and what it means. Read on.
OK, gratuitous complexity is a Bad Thing.
But:
What was once complex (cool!) can be become simple (yawn!). Virtual addressing was once so exotic a technique that some IBMer devised the ThingKing story to get the idea across to people.
Objects were once a trick. The idea of encapsulation was once cutting edge. As was writing threaded code. As was messaging a remote system. As was using persistent declarative storage.
These are now, more or less, routine things to do. Simply because people kept reaching into their bag of tricks and pulling them out.
But, how many of these techniques were simple enough to be the simplest thing (assuming they weren't the only thing) when they first appeared on the scene? NotaRhetoricalQuestion
I submit that new techniques are more complex because:
If XP has some measure of complexity different from: what the developers collectively understand are comfortable with today, please share it with us. -- KeithBraithwaite
That's a good measure. XP says that if your project's purpose is to deliver business value on a schedule, you should build only with code the developers collectively understand. GemstoneConsultingStory.
-- RonJeffries
What I (KB) am trying to get at is the process by which techniques such as those mentioned above get from the bottom of the bag to the top. For many of those techniques, this happened a long time ago, and some people here on Wiki saw some of it happen.
But the process hasn't stopped. What is the XP take on this (ongoing) process?
Objects were once not main-stream. They were never a trick. They were used as a simple way to solve problems which could not be addressed any other way. As such they were the simplest solution which could work. I suspect the other examples given are the same. -- DonWells
Semantics. Or, as Jack Nicholson once said, while playing Jimmy Hoffa, "Words. Words. More words. What do they mean. Words." What does this mean?
This originated in PropellerBeanie. Which referenced the "bag of tricks." If you want to argue that deviating from standard practice to solve a thorny problem isn't using a trick, fine. But I think your usage is probably just a tiny bit unclear.
This originated in PropellerBeanie. Which, as I read it, is an attempt to use peer pressure to prevent people from thinking out of the box. Emphasis mine, not William's. -- RJ
Possibly appropriate in industrial situations. But, in general, the sort of thing that would have us still programming in COBOL on mainframes. Inappropriate attribution removed. -- RJ
see also VagueWords
Bag of tricks may not be clear. There is no intention here of keeping people from thinking out side of the box. In fact it is encouraged. What is meant by digging too deeply in the bag of tricks is different. If you for instance find yourself copying code out of DonKnuth's Algorithm books, you may be digging too deep. It is very easy and tempting to throw something at a problem that you know positively will work. Something from your bag of tricks that you learned or have used in the past. It is much harder to step back think about it and create a new solution tailored to your exact needs of today. Bag of Tricks as used here is in reference to over engineering a solution and thus making it more complex than it actually needs to be. Or as RonJeffries pointed out to us, don't go writing your own perfectly optimized sort algorithm when the built-in one works just fine. -- DonWells
I think what Don is getting at here (not wishing to put words into your mouth, Don) is the difference between complex/difficult coding required to solve complex/difficult problems and complex/difficult code used to solve relatively simple problems. I work with some extremely clever people (a PhD in theoretical physics or algebraic theory is the norm rather than the exception) who often get very excited about extremely clever solutions ... even when they're not required to solve a business problem. Re-define #doesNotUnderstand, use the Smalltalk meta-information, write your own bespoke reflective layer - all good tricks that have their place ... but not necessarily the first things you should jump for when you need add a new log-on procedure or a new data screen.
-- PaulDyson
Suddenly we're preaching to the choir here. The folks who asked the question didn't listen to the answer, didn't like what they thought the answer was, called us names, took their ball, and went home.