Do The Simplest Thing That Could Possibly Work

A lightweight stick that is used to beat down arguments in XP projects. I came to XP thinking that the above mantra was the greatest thing since sliced bread. I still think it's a great mantra, but it needs to be taken with a grain of salt. Why? You might ask. I have seen it used too many times to disregard a potentially good idea simply because someone didn't want to think. To me, agile is about being pragmatic and delivering business value without unneeded overhead. This takes care, patience, and most importantly thought.. I get frustrated with XP because of the dogmatic mantras that developers sling around to avoid pondering alternative solutions.

I believe you should at least reason about your problem a little bit before coding. Just don't jump right in and start coding away like a mad man. I'm not talking about documenting detailed UML models with long descriptions before coding either. A simple whiteboard session to get the bird's eye view. I've found an hour or less is perfect. I find that flushing out ideas in front of a whiteboard before coding gives everyone the vision to implement the code correctly. Vision is an important aspect of team software. It gives everyone the high level perspective to know how their piece will fit in. It also gives everyone ample opportunity to speak their ideas. But, I have found in XP that coding is the king and that vision is never matured and every pair implements their piece. Guess what? The pieces don't always fit. So, we have to refactor mercilessly where a simple whiteboard session could have saved hours (and in some cases days). A stitch in time saves nine. How true.

The fact that some developers use the mantras, "Do The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need", to shoot down ideas and be the devil's advocate is annoying. It's used when an idea is not understood by certain members of the team (which is not a good thing, but discussion helps understanding). I've seen this phenomenon too many times to count. Being agile doesn't mean throwing your brain out of the door. The confusion arises in the fuzzy nature of these sayings. From who's perspective are we talking? Simplest for the developers? The users? The managers? Who? I generally take it to mean "The Users". But, most developers take it to mean simplest for them. And then, there's what people's definition of simplest is. Some think simplest means easiest and others think it means most convenient. Ironically, I take the simplest possible thing for the user and using the simplest (not the easiest, but the one with least moving parts) design. Sometimes, I think I stand alone on this. But, I know other developers take the same definition.

For example,what is simplest XML files or relational databases for object storage? Now, before I even get started it is true that you can hide the storage mechanism behind objects and plug-n-play the solution. But, is it really that simple? While, yes, in theory, I should be able to unplug one solution and plug in the other using the strategy pattern. It assumes developers will never break encapsulation (aka "Look at that private method, change it to public! We need to use it!) and the discipline is in place to make sure the interface is strictly enforced (aka "Look this interface is too coarse grained...let's add a bunch of small grained methods...this ain't no sippin' broker!"). In practice, you will have developers of varying expertise and once encapsulation is broken, you can no longer plug-and-play your solution without major refactoring. Also, little assumptions are made along the way that can degrade the quality of the interface (aka "Man, this file broker performs awful! I know, let's create a summary object and store it as well!"). Again, I get back to developers need to have discipline and vision so that the design allows the strategy pattern in our storage brokers to remain in tact. Otherwise, our interface is compromised and our membrane of encapsulation collapses into endless refactoring.

OK, I got off the discussion of XML files versus relational database storage. Which is simplest? You could argue that file storage is the simplest from the point of view of just storing objects. Right? If you are at the point of deciding storage, you are in the infant stage of your new product. Files will be nice to get the objects right before dealing with the headache of OO to relational mapping. So far so good. We are being pragmatic right? But, what about the view point of concurrency? ACID transactions? searching? Are files still the simplest possible thing? I don't think so and here's why: relational databases have been tuned by experts, people who make a living thinking about transactions, concurrency, security, and searching. All of which are not trivial topics. Now, my purpose in my job is to deliver value to my customers. How is making a file system searchable, concurrent, and acid delivering business value? It's not. So, I pay a small penance to the complexity gods to enjoy the fruits from the blood of the experts. You have to look at the bigger picture. Delivering a production enterprise system using a file system is bordering on gross negligence. I know it has been successful for certain startups (Paul Graham comes to mind, but he had the "best of the best" working for him, I'm talking general enterprise development in corporations). Of course, an even easier solution would be to use an object database, but I realize it might not be an option for everyone.

You might be thinking that I am against "Doing The Simplest Possible Thing", but I am not. I think it should not be a gauntlet that is thrown to stop arguments. I don't think it should end discussions. In fact, I think it's a value that doesn't need to be brought up in discussions. It's something to internalize and not used to make your easy solution win. You live and breathe it. You show others through example. I consider myself to be agile and not XP. I'm deeply pragmatic and think about my solutions. Dogmatic mantras are tools to not use your grey matter. Simple solutions do not just pop out of thin air. The simplest thing takes thought and understanding of the problem from all angles. It also takes practice and knowledge. The worst idea is to only have one. Experts make the simple look easy. How many people read the GoF patterns book the first time and said to themselves, "Wow, why didn't I think of that?"