small_car.jpg

Why Small is Better

I’ve talked about large backlogs being fatlogs here and here before, but I’d like to apply that general thinking to more than just backlogs, and talk about why I think small is almost always the right choice.

We can apply the principles I am about to describe in a variety of contexts.

  • Determining how to best slice up a fatlog
  • Adding tasks to a backlog
  • Refactoring or writing methods
  • Creating database tables
  • Designing a UI
  • Designing an API

small car thumb Why Small is Better

Small = Simple

Software development, or rather software craftsmanship, is about managing complexity.  It always has been, it always will be.

Small things are typically more simple than large things.  Constraining size forces us to constrain complexity.  This is good.

We can built very large seeming complex things out of simple blocks.

Consider the reason why we break up our code into methods instead of writing it all in the main block.

A simple design is the difference between having a 10 year head start on the mobile phone industry and creating a phone that everyone hates and only ends up using as a basic phone, versus releasing a phone and in a very short time changing the world.

Small is easy to understand

This reason is essentially the same as simple, but is worth its own treatise, because it is so important.

Having a unit of work that is easy to understand greatly increases the chances that it will be:

  • Done right
  • Done at all
  • Done quickly
  • Communicated and passed on correctly and easily

Small things are easier to understand.  Almost any complex concept can be broken down to small enough pieces that it can be understood.

You will be amazed how much more work gets done when people understand the problem they are trying to solve.  Which brings me to the next topic.

Problem admiration

There is nothing… and I mean nothing, that will hamper productivity like problem admiration.  If someone thinks a problem is large and complex they will sit and admire that problem instead of working on it.  It is basic human nature.

Look at your own life.  Look at successful programs for life organization like Getting Things Done.

  • Why aren’t you cleaning your garage?
  • Why aren’t you finishing up that degree you wanted to get?
  • Why aren’t you getting in shape?

Most likely it is due in some part to problem admiration.

I’ll give you a hint to cleaning your garage.  Break the work up into 10 – 15 small tasks.  Watch how much easier it will be to accomplish that goal.  Give it a shot.

It is hard to admire a small problem.  Take big problems and make them small problems whether you are designing a database, cleaning your garage or slicing up a backlog item.  Small is better.

Evolution

Iterative development is about evolving software.  We evolve software because of the feedback loop.  Short feedback loops are good because they allow us to adjust.

Have you ever had a really bad remote desktop connection?  What happened to your mouse when you moved quickly in one direction?

Makes it hard to control doesn’t it?

The smaller the piece of software you build, the shorter the feedback loop is.  If you want to control the evolution of your software, make the feedback loop short.  If you want to make the feedback loop short, make the slices small.

Estimation

Want to know how long it will take me to write code to reverse a string?

  • About 5 minutes.

How about how long it will take me to write this blog post?

  • About 30 to 45 minutes.

How about how long it will take me to build a dog house?

  • I don’t know.  About a day maybe.

How about how long it will take me to write a book?

  • I have no idea, but if you make me guess I would say 5 months give or take 5 months.

Excuse the crappiness of my examples, but I hope you can see my point.  The smaller the item is, the easier it is to estimate the time it will take to complete.

If you have been working in software development for any length of time you have probably come to the realization that tasks estimated to take an hour usually take an hour, but tasks that are estimated to take one day rarely actually take one day and sometimes end up taking a whole week.

Think about a more practical example.  Can you show me with your hands how big 1 foot is?  Okay, now look outside and eyeball 500 feet.

Progress

There is no better motivator than making progress.

This benefit is purely emotional and artificial, but we are emotional artificially inspired beings.

Everyone loves making progress.  If you break things down small, you can chart your progress and see that you will indeed finish.

Imagine a progress bar with 2 big blocks.  Wouldn’t be very inspiring would it?

  • http://www.bryan-weaver.com Bryan

    Great post! I have been working on this lately. Things were piling up and I was having a hard time managing my time. Home projects, work projects, personal projects, school stuff, finance goals, etc.

    Breaking all this down into smaller units of work has really helped. I write down all my goals and break each one into weekly tasks.

    For finances I have been auditing all my spending and refactoring my cash flow. In the past 8 months I freed up nearly $500 a month, by getting rid of rarely used services and consolidating bills. I think I have optimized the expenses as good as it is going to get for the time being. Time to work on increasing the income side.

    At home I have slowly been going room to room and clearing out stuff I dont need. Its amazing what you accumulate over time. I start by completely emptying the room, furnature and all, and only returning the items I use. The leftover pile gets tossed or sold.

    Now, I believe it is time to dump Windows Mobile 6.1. I was actually considering heading back to a “stupid” phone. I am rarely far from a PC and between RDP, LogMeIn, and Dropbox, I can get to my data pretty quickly. However, those Androids phone are pretty sexy. :)

  • http://blog.gfader.com/ Peter Gfader

    +1
    Great post!
    Small tasks are important for motivation and 1 of the reasons why I love Scrum

    What do you think about Code Contracts? (.NET4 includes them finally)
    I realized that if you have Code Contracts in place (pre and post conditions, class invariants) you tend to minimize the functionality of your methods, just to match the code contracts.
    Result: Smaller methods.
    With refactoring you are getting there too, but from a different way…

    • http://simpleprogrammer.com jsonmez

      I need to take an honest look at the .NET 4 Code Contracts, but in the past I have not really liked code level contracts because of the amount of overhead and time involved in creating them, vs the benefit. I have found a unit tests to be a good specification for the behavior of a method that gives context as well as behavior information.

      I would like to take a look again though to see if I would change my mind.

  • http://blog.gfader.com/ Peter Gfader

    I was thinking about Code Contracts in general.
    Since .NET includes them now you should give them a go!

    >>because of the amount of overhead and time involved in creating them
    They make us devs think a bit more before we start up typing, which is good… Less time to write unit tests…

    >>I have found a unit tests to be a good specification for the behavior of a method that gives context as well as behavior information.
    But unit tests are so far away from your code.
    Code Contracts are next to the method and easier to read.

    I am looking forward to a blog post about those!
    CU

  • Pingback: Avoiding Procrastination Through Pairing « Making the Complex Simple()

  • Pingback: My End of the World Post « Making the Complex Simple()

  • Pingback: 7 Reasons Why You Should Tackle Hard Problems Last | Making the Complex Simple()

  • Pingback: 5 Things That Will Make Your Agile Development Project FAIL!()