Thursday, January 12, 2006

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?"


jhemmelg said...


Don't conflate the feigned ignorance of the devil's advocate with XP methodology. These people would be sabotaging your effectiveness no matter what banner they flew. The principle is "Do the simplest thing THAT COULD POSSIBLY WORK". That depends on what you are trying to accomplish this iteration. If ACID, concurrency, etc. are requirements of this iteration, by all means go with the database. If they aren't, you may still decide to use a database, but you don't have to. If you are in an early iteration you may choose to use files because they give you better debugging capability. Your experience is also key in this: If you have enough domain knowledge to know that you need a database, stick to your guns. You must communicate this to your colleagues.

I think if you talked to the originators of XP they would agree with your approach to planning. Design and programming takes a lot of thought to do right. It is not for the mentally lazy, which is what it sounds like you are running into. It also sounds like you have some cowboys on the team. XP is very much about communication within the whole team which should avoid the clashing implementation problem.

One other point: It sounds like you are concerned about needing to refactor. XP accepts that ALL software is going to change no matter what the methodology involved in creating it. Encapsulation will be broken no matter what you do. It will always be somewhat painful to switch the implementation of your data store for example. The key is to accept that this will happen and have the courage to tackle it as you find it and refactor the code instead of programming around it and letting a big ball of mud accumulate. (That's how the broken encapsulation usually starts - somebody programming around something rather than thinking about the design and refactoring)

Good luck, and remember - it's only programming!

Unknown said...

Thank you for your comments. I'm not concerned with "needing to refactor" per se. But, I am concerned with refactoring unneedlessly. I understand changing requirements and being quick on your feet. You have to be or you'll be dead in today's market. But, I also understand to be nimble on one's feet, you must reduce refactoring by thinking about your design. Experience tells you what you'll need and will not. A good designer makes this distinction and that's why they are worth their weight in gold.

I know user's will change their mind, but mostly infrastructure concerns from project to project remain roughly the same.

My point is to remain agile and reduce the amount of work you don't do.

John P said...

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?"

Pretty much, I did. I didn't use the wow word, though. Bad day at the office, Blaine?

-- Mr. Too Analytical

Unknown said...

Hehehe, yes, it was a bad day at the office....=) I shouldn't type when mad.