Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

OO Design Principles

Thursday, June 7th, 2012

Following Object Oriented Design Principles have really helped me designing my code:

Along with these principles, I’ve also learned a lot from the 17 rules explained in the Art of Unix Programming book:

  • Rule of Modularity: Write simple parts connected by clean interfaces
  • Rule of Clarity: Clarity is better than cleverness.
  • Rule of Composition: Design programs to be connected to other programs.
  • Rule of Separation: Separate policy from mechanism; separate interfaces from engines
  • Rule of Simplicity: Design for simplicity; add complexity only where you must
  • Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
  • Rule of Transparency: Design for visibility to make inspection and debugging easier
  • Rule of Robustness: Robustness is the child of transparency and simplicity
  • Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
  • Rule of Least Surprise: In interface design, always do the least surprising thing
  • Rule of Silence: When a program has nothing surprising to say, it should say nothing
  • Rule of Repair: When you must fail, fail noisily and as soon as possible
  • Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
  • Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
  • Rule of Optimization: Prototype before polishing. Get it working before you optimize it
  • Rule of Diversity: Distrust all claims for “one true way”
  • Rule of Extensibility: Design for the future, because it will be here sooner than you think

Ten Laws of Simplicity by John Maeda

Monday, August 30th, 2010

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:

Simplifying a Complex Design

Thursday, July 15th, 2010
From

To

I know TDD coz…

Friday, May 14th, 2010

Just because you know the syntax of a programming language, does not mean you know programming

Just because a toddler can make some sounds, does not mean she can speak

Similarly, just because you write tests before you write code, does not mean you know TDD.

TDD is a lot more than test-first. IMHO, following concepts let’s you truly experience TDD:

  • Evolutionary Design,
  • Acceptance Criteria,
  • Simple Design,
  • System Metaphor,
  • Thin Slicing,
  • Walking Skeleton/Tracer Bullet and
  • Interaction Design

How long does it take a dev to be well-versed with TDD?

Depends on the dev, but atleast a couple of years of deliberate practice on projects

What can we do to become TDD Practitioners?

Start with deliberate practice in safe env. Then gradually start on your project.

Goodbye Simplicity; I’m Object Obsessed

Monday, October 26th, 2009

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).

Snakes And Ladders

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.

Avatars of TDD @ CodeChef TechTalks, Bangalore

Monday, September 28th, 2009

Recently I presented on Avatars of TDD at CodeChef TechTalks in Bangalore.

Artifacts from the tutorial:

(Yes, that’s me talking. Even though you can’t see me you have to trust me.)

For the demo, I used Alistair Cockburn’s problem from OOPSLA DesignFest. Feel free to download the source code from the demo.

Embrace Simple Design

Wednesday, May 20th, 2009

In Software if we wanted to build, bathroom showers, most of us would have built the following:

A mounted shower with a separate hand-shower. To think about it, you are always going to use only 1 at a time. Why then do you need both?

A smarter way to build a shower would be:

If you want to use the mounted shower you can, if you want to use the hand shower you can. The water controllers are massively simplified and it does what you need. 

This is what I refer to as “Smartest Possible Thing That Could Possibly Work”

    Licensed under
Creative Commons License