My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
For the last few months, I've been having trouble getting out of "next week" mode. That's what I call it when I don't know what I'll be working on outside of the next week at any given time. It's not necessarily a bad thing, but when you're working on projects that take longer than a couple of weeks, it doesn't let you keep the end in sight. Instead, you're tunneling through the dirt and hoping you've been digging up instead of down.

An photo of a mole by Michael David Hill.

I've delivered most projects during this period on schedule, but I did cave into pressure to over-promise and under-deliver on one occasion. And it sucked.

When I wrote that rewarding heroic development promotes bad behavior, I said reducing the risk and uncertainty of project delivery is the subject of a different story, and the discussion in the comments got me thinking about this. There are many stories worth telling regarding this issue. The rest of this story is about how I'm intending to get out of my funk using techniques that have worked for me in the past.

(Aside: As I write the words below, it occurs to me we have a chicken/egg problem of which comes first. Just start somewhere.)

To make decent estimates there are 3 must-haves:
  1. Historical data as to how much you can complete in a given time frame
  2. Backlog of items you need to complete in the time frame you're wanting to estimate for
  3. The ability to break requests into sweet, chunky, chewy, bite-sized morsels of estimable goodness.
Sweet, chunky, chewy bite-sized morsels

Since you haven't been doing this ["ever", "in a while"][rand*2], you don't have historical data. Your backlog is anything on your table that hasn't been completed yet - so you've got that. Now, you need to break your backlog apart into small enough bits to estimate accurately. This way, you practice the third item and in a couple of weeks, you'll have historical data.

About estimating tasks: Don't worry about estimating in units of time. You're probably not good at it. Most of us aren't, and you haven't even given it a fair shot with some data to back up your claims. Measure in points or tomatoes. Provide your estimate in chocolate chips. The unit of measurement doesn't matter at this point, so pick something that makes you happy. However, you should stay away from units of time at this point in the exercise. You're not good at that, remember?

So I have some number of tasks that need to be completed. I write each of them down, and decide how many chocolate chips it's going to take me to finish each one. I count in Fibonacci numbers instead of counting numbers, because as tasks grow in time and complexity, estimates grow in uncertainty. I try to keep all of my tasks as 1, 2, or 3 chocolate chips. Sometimes I'll get up to a 5.

But if you start venturing into 8 and 13 or more, you're basically saying IDFK anyway, so you might as well be honest and bring that out into the open. Such tasks are more like Chewbaccas than chocolate chips, so take some time to think about how you might break them down as far as possible.

Sweet, chunky, Chewie bite-sized morsels
photo by Bonnie Burton found on starwarsblog photostream licensed CC Attribution 2.0 as of 5/21/2009

Now that you know how to estimate tasks: Before you start on a task -- with a preference to earlier rather than later (hopefully as soon as you know it needs to be done) -- estimate how many points it should take you, then write it down on your list of items to complete. Take note of how many chocolate chips you finish daily. Write down the number completed and the date.

Make a graph over time comparing the number of chocolate chips you have remaining (or how many you've completed) on the Y-axis and the date that applied to. If you use points remaining, it's a Burn Down chart. If you go the otherway, it's not surprisingly called a Burn Up chart.

A simple burndown chart.

Keep a log of the number of chips you complete per week. The last two or three weeks' averages are a good indication of how many you'll be able to do for the next few weeks, and helps planning for individuals spanning several projects, or teams on a single project.

You can now reference your chips per week to extrapolate how long it's likely to take you to finish a particular task or small project.

Further, you'll always want to know how many points you've got in your backlog and how many you need to complete by a given date. If you keep a log of due dates you can reference it and your points per weeks when someone asks you when you can have something done. Now, you can say "I can start on the 26th or you can rearrange the priorities on my current work and I can be done by the end of the day."

Any questions? As always, I'm happy to answer them.

The majority of these ideas are scrum-thought and I've used terms from that methodology, so if you want to go deeper, that would be a good place to look.

What is do you do for planning and estimation?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner