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