In software world we call this speculative generality or YAGNI or over engineering.

IMHO we should not be afraid to throw parts of your system out every 6-8 months and rebuild it. Speed and Simplicity trumps everything! Also in 6-8 months, new technology, your improved experience, better clarity, etc. will help you design a better solution than what you can design today.

Just to be clear, I’m not suggesting that we do a sloppy job and rewrite the system because of sloppiness. I’m recommending, let’s solve today’s problem in the simplest, cleanest and most effective/efficient way. Let’s not pretend to know the future and build things based on that, because none of us know what the future looks like. Best we can do is guess the future, and we humans are not very good at it.

You might think Definition of Done (DoD) is a brilliant idea from the Agile world…but the dirty little secret is… its just a hand-over from the waterfall era.

While the DoD thought-process is helpful, it can lead to certain unwanted behavior in your team. For example:

• DoD usually ends up being a measure of output, but rarely it focuses on outcome.
• In some teams, I’ve seen it disrupt true collaboration and instead encourage more of a contractual and “cover my @ss” mentality.
• DoD creates a false-sense/illusion of doneness. Unless you have real data showing users actually benefiting and using the feature/story, how can we say its done?
• I’ve also seen teams gold-plating stuff in the name of DoD. DoD encourages a all-or-nothing approach. Teams are forced to build fully sophisticated features/stories. We might not even be sure if those features/stories are really required or not.
• It get harder to practice iterative & incremental approach to develop features. DoD does not encourage experimenting with different sophistication levels of a feature.

I would much rather prefer the team members to truly collaborate on an-ongoing basis. Build features in an iterative and incremental fashion. Strongly focus on Simplicity (maximizing the amount of work NOT done.) IME Continuous Deployment is a great practice to drive some of this behavior.

More recent blog on this: Done with Definition of Done or shoud I say Definition of Done Considered Harmful

Recently I stumbled upon John Maeda’s book: The Laws of Simplicity.

He has a very interesting take on Simplicity. In this book he describes:

TEN LAWS

1. Reduce – The simplest way to achieve simplicity is through thoughtful reduction.
2. Organize – Organization makes a system of many appear fewer.
3. Time – Savings in time feel like simplicity.
4. Learn – Knowledge makes everything simpler.
5. Differences – Simplicity and complexity need each other.
6. Context – What lies in the periphery of simplicity is definitely not peripheral.
7. Emotion – More emotions are better than less.
8. Trust – In simplicity we trust.
9. Failure – Some things can never be made simple.
10. The One – Simplicity is about subtracting the obvious, and adding the meaningful.

THREE KEYS

• Away – More appears like less by simply moving it far, far away.
• Open – Openness simplifies complexity.
• Power – Use less, gain more.

I found some slides which are also interesting:

In retrospect, I think Object Orientation has tremendously helped me become a better programmer. But at the same time, its also made me vulnerable to including extra complexity (or at least thinking in terms of more complex solutions) in my code.

One of the important lessons I learned a few years ago was, not to try and model my software on real world (my perception of reality). This leads to my software solution ending up as complex and easy to misunderstood as the real world. Soon I started embracing “There is no Spoon” philosophy and really focusing on abstractions.

Last year, I was again caught red handed, trying to sneak in too many objects (and hence complexity) into my code. This time I was pairing with another developer new to TDD and we were building a Snakes and Ladders game using TDD. The focus was really demonstrate TDD in a very different context.

(I’m sure everyone is aware of the Snakes and Ladders board game).

30 mins into the pairing, we had the following classes with wonderful tests for almost each class:

• Game
• Board
• Player
• Dice
• Snake
• Ladder

Just then Sandeep Shetty was passing by and he looked at the beautiful piece of mess we had created. He was surprised how royally we were wasting our time. The following 15 min discussion helped all of us realize how we were so caught up in TDD and coming up with all those (useless) abstractions when simply we could just have

• one class called Game (place holder, the class is not really required) with
• one method called move(int number_on_the_dice)
• a list to hold the current position of each player on the board (there can be more than 2 players)
• a hashmap with starting and ending points on the board (represents both the snakes and ladders, how does it matter whether its a snake or a ladder, they are just starting and ending points on the board)
• a counter to calculate player’s turn
• and … and what? …that’s it

Can you beat the simplicity of these 15 odd lines of code? Its not really about the number of lines of code, its about the conciseness and simplicity of it.

Refactoring Teaser IV is another great example of “Death by Objects” pattern. Solution Summary highlights the real difference.

I would also suggest reading Embrace Simple Design, an analogy and a recent example of Object Obsession.

As time passes by we notice that

• The Software bloats up
• The Team bloats up
• The Process bloats up
• The planning phases bloat up
• The Documents and artifacts bloat up
• Bugs bloat up
• Team members bloat up
• The organization bloats
• and so on….

What we need is some jigging to shake off all those extra fat. Unfortunately organizations adopt the “more the merrier” philosophy instead of “less is more” or “less is beautiful” philosophy.  Why not embrace simplicity? 

Simplicity is defined as “the art of maximizing work undone”.