Waiting For Simple Ideas

A simple solution takes significantly less time to implement than a complex one. Waiting for the simple ideas to come is actually faster.

I discovered many years ago that trying very hard to hammer out a solution without a good, simple, elegant design was almost impossible. It took enormous amounts of thought just to get something coded, it took long hours to get it half way working, and then it took forever to find all the bugs and fix them. Meanwhile, someone who took the time to figure out a way to implement it in a few well-crafted lines of code was already done.

I have worked this way ever since. I have suffered criticism, threats of dismissal and even the dreaded BrutalSarcasm because of it. But by adhering to this principle I have never been late to a deadline. When I stray from this principle, I am always late. Simple.

I have modified my application of this principle in one very important way. When I was working with KentBeck on the fabled ChryslerComprehensiveCompensation project, he taught me not to literally sit and analyze the problem till I had an idea. Instead, he taught me how to conduct experiments to gain greater insight. Try coding up a couple solutions. Yes, they will be ugly. But what I found out and Kent no doubt already knew is that when you code a couple attempts at a solution you will notice that there is a common core or common theme between all the solutions you might be considering. All of a sudden, the simple idea presents itself.

Now to do this you must avoid the urge to proclaim yourself done as soon as the first experiment is coded. You must throw it away and start again and again till you find the simple solution. It's always faster and cheaper to throw away complex code now, no matter how much is already invested, working or not. -- DonWells

Don't just do something, stand there.

I had a similar experience just this month. I was coding a package for which I didn't know the right design - I knew some requirements and had some idea of how to do it, but I didn't think that would work. So I got in and wrote some code to do the things I understood. As I got to the end of those things, the better design came to me, naggingly hanging around in the back of my mind, until I decided that the only way forward was to go back to the beginning with the new design. But that's good, if I hadn't spent all the time with the wrong design I don't think the right design would have come along. In one afternoon, I went from 2600 lines of code to 2000 lines of code without losing functionality. -- JohnFarrell

I HaveThisPattern! For the longest time, we usually just called it putting something on the "back burner" or in the "slow cooker"! That meant we didn't have a good answer yet and decided we needed to let it stew in our minds in the background for a bit (clearing it from our foreground thoughts ;-) and then revisit it later when the idea finally came, or when it couldn't remain in the background any more. -- BradAppleton

I've heard it called letting the idea "percolate". -- ChrisHines

I've been stumbling towards something like this for the last couple of years. What I usually tell people is that the solution will come when the problem is ready for it. However, in order to avoid dismissal (or even BrutalSarcasm) and still gain enough time for waiting, it becomes necessary to engage in a lot of secondary behaviors: CommunicateJustEnoughDesign, FocusOnCompletedSolutions?, FocusOnShortTermGoals?, AdmitYourIgnorance?, and I'm not above stooping to sowing a little FUD when desperate, like distracting people with really big, unsolvable problems.

More often than I like, I feel that I've wound up compromising the basic principle or that I'm not dealing entirely fairly with my customers, no matter how unreasonable their demands for BigDesignUpFront may seem to me. Are there techniques or examples of more graceful ways of getting enough time to wait in unreasonable circumstances? -- MikeKrajnak

Deliver business value.

See Also: RefactorSlack

Seems to me that the thing about knowing a simpler solution is to know another solution. Then (I'm serious here) one of them is simpler. I've watched people slog for hours through horrible ugly solutions, not really enjoying it, not really knowing what to do.

What I find useful is to completely ignore the objects I have and think about how easy this would be if it was all I had to do, starting over. I write a SpikeSolution from scratch. I think about how simple objects to do my thing would interact, if they didn't have to deal with all this history, and code that. That lets me get to the core of the solution, and usually points the way to what should be done in the real objects. -- RonJeffries

I also do this but occasionally get killed by a hidden dependency i.e. it only works if the system isn't snarled up already. Perhaps why XP doesn't work too well in legacy environments. Managers want an incremental tweak, not a wholesale rewrite. -- RichardHenderson

Do ideas equal solutions? It seems that those who entered the discussion have missed the point of "Waiting for SimpleIdeas?" by introducing notions such as "you get to simple solutions by refactoring several quick and ugly solutions (which is like saying "try several approaches" and find in them a common thread, or "to completely ignore the objects I have" (and start over by understanding what interactions are necessary). This seems to sound like "If you are having a tough time with the SimplestThing, perhaps you should devise a plan which will lead to an apparent solution." Isn't this like saying "Don't stand there, do something"? Where is the waiting in this approach?

Sometimes a good night's sleep or a vacation will help one form a fresh view of a problem.

There are two important things here: one is being patient enough to let your mind work and the other is being busy enough to give that mind something to work with. These are subtle things. But giving up early and taking a bad solution hardly ever pays off big. -- WardCunningham

The above originally said "begin busy enough", which I believe was a mis-print and I have corrected it. The following is based on that mis-print. Can it be salvaged?

Perhaps we can illustrate this frame of mind with the following quote: What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. From: DoTheSimplestThingThatCouldPossiblyWork (originally in an interview involving KentBeck).

This is not waiting, it is doing. This is not originating, it is modifying. A solution using such thinking is but a first step in a series of solutions implemented to satisfy a specification, a model, an idea or a plan that already exists. It is the act of changing existing things into new things utilizing SufficientExpertise. Such a frame of mind is not one content with waiting, but rather one intending action. (which is preferable)

Managers and other dependent team members may not like the idea of just waiting. They suffer the loss predictability and synchronization points. Can we balance the waiting against predictability and co-ordination?