Robert on Software Development

We are in the throes of development of our product, and while coding marches on, we’re asked on a near-daily basis: when will it be done?

That’s a tricky question, one that has plagued developers and managers for years. There are countless books on how to estimate software development, and it seems everyone has his or her own idea of how it should be done. In my own personal experience, I’ve seen everything from determining the number of lines of code and calculating based on that (part of the CMMI Personal Software Process) to plugging the number of ASP pages in an Excel spreadsheet and ending up with a time based on some arcane calculation.

In my current project, we had to face the specter of determining timelines this week, and without a clear vision of what “complete” means, we have to take things step by step. We had several choices for our estimates.

The first option involved using the traditional time-based estimate. “This will take three hours,” or “I think this will take two days.” This type of estimate is good for determining a stop date for development, and managers like it. However, it can be very inaccurate and put the developers in a position where they have to defend against accusations of failure. Because we’re learning about our vertical market and WPF at the same time, it’s extremely difficult for us to get any accuracy on time and date estimation.

When I was at HP, we used a “level of effort” estimation. The first iteration for the LOE was 150%. In other words, the project’s timeline would be met somewhere between –150% and +150% of the initial estimate. So if we said 10 days, it could be done as late as 25 days (-5 days wasn’t really an option). In the second iteration, we reduced it to 50% LOE, and then finalized on 30%. In a big project, a 30% LOE can be a huge variance. Consider a project with dozens of developers and thousands of hours of work. A 30% LOE on a 14,000 hour project is 18,200 hours. If you’re paying by the hour, ouch.

The second option we looked at was the one we went with: relative sizing. Rather than evaluate a task in terms of how long it would take, we looked at how difficult it was. Each task is given a number based on the Fibonacci sequence (1, 2, 3, 5, 8…). A “1” is very simple. A “2” could be more complicated, but still pretty easy. And so on, until you reach the upper numbers, which imply that the task is extremely difficult and should be further broken down.

We looked at one of our key deliverables and broke it down into a couple dozen tasks. Then we got together as a group and sized each task. Creating a screen might be a 2, while developing its databinding is a 3. We wrote down each task on a sticky note and put it on our board. Each week, we go through the tasks and choose the ones that will be “on deck” for that week, and put the rest in the backlog. The developers then assign themselves tasks, one at a time, based on the difficulty of the task and their comfort level with it.

One of the nice effects of using this technique is that upper management (including myself) can look at the board and get an idea of what’s going on at any given time. Each task’s progress is also tracked in our daily scrum reports, which are logged online. If a developer needs help due to a roadblock, he makes a note in the scrum report and we figure out how to solve it.

At the end of each week, we look at the results of the sprint and decide if our estimation of what we could complete is accurate, and we adjust the following week’s tasks accordingly. This is called establishing velocity. We are able to determine what our work product is from week to week, and make a determination on how long something will take by looking at evidence from previous sprints. If Developer A takes an hour on average to complete a 1, and three hours for a 2, then we can determine that within a 30 hour productive cycle that he can do 30 1s or 10 2s, for example. It’s not supposed to be that precise, but rather give us an idea of what we can expect.

We’re young with this process, but I feel confident about it. I need to be able to respond quickly to removing roadblocks for the developers while also producing my own work output. By viewing the board, I see what is going to be done, and by participating in the board, I set the expectation for my own work.

In my next post, I’ll discuss hierarchies of the individuals involved and how interaction works between them.

Where has the time gone? My last entry was on July 29, 2009. To say that a lot has happened since then would be a grand understatement. The short version is that I left the world of SharePoint consulting and accepted a full-time position at a software company here in Des Moines. As the Director of Product Development, I serve in multiple roles. Product architect. Project manager. Software developer. Tech lead. You name it, I do it. I have a team of eight people, including developers, QA, and documentation.

This job was a dream come true for me and to be honest, accepting it turned my life upside down. I canceled my plans to move to Dallas and start my SharePoint consulting firm. I canceled my SharePoint certification tests. I ceased all work on Flipism. And most surprisingly, I bought a house. I decided to fully invest in this new opportunity, and I accepted all the risks that came along with it.

We are developing the application in C# 3.0 and WPF. I decided to build the application in WPF because I believed it offered us the most flexible platform for future opportunities and growth. It was a risky gambit, partly because nobody on the team knew WPF. I had a limited exposure to it from my days at HP, but I was hardly an expert. But my team pulled it together and we took the plunge into WPF. While I acknowledge that developing the product in WinForms would be “easier,” I don’t think that it would make our product better. WPF has given us many gains, and the architecture lends itself well to our future plans.

I’ve learned so much since I started on August 31. While the company has been around for several years, my team is brand-new, and the product we’re working on is brand-new. We’ve all had to learn how to work together. We come from different corporate cultures and technical backgrounds. I’ve had to draw on the entirety of my experience in order to lead this team, but I love it. Love love love it. I feel like every decision I’ve ever made in my life and career has led to this. It’s hard for me to feel regret about bad choices I made when I was younger because I might not have been led to where I am now. I know that sounds corny, but it’s true.

Obviously I have a lot of hope about the future and the change it brings. And to that point, the focus of this blog has to change as well. Pretty soon I will relaunch this blog to focus on my experiences as a leader in a software company. Hopefully what I share with you here will be of interest, or at least entertainment value.

So tell me: do you want to come along for the ride of your life?