Reducing Schedule Risks: Feature Branches

Software development projects are subject to a number of risks. One of these risks is schedule risk. By this I mean that you may not be able to ship on time because of some nasty discovery while executing the project.

Of course you don’t know what you don’t know. You cannot foresee what you will discover as you work through the project plan (or backlog). No matter how much effort you put in planning your project, breaking down the stories, even running some spikes, you will find that you cannot totally eliminate surprises that add to your workload.

Although we cannot totally eliminate that risk there are techniques that help with mitigating it. Firstly you can build in an allowance for discovery into your plans. Some people would call it a buffer.

A different option is to break your deliverable into multiple features. Often you will observe that most of the features are completed within the deadline while a small number may overrun. You will run into a problem, though, if you are using a single branch in the version control system (VCS) for your work. Your only option will be to deliver late once all features are complete.

Therefore a different approach is using feature branches. For each feature that you have scheduled you create a separate branch. Once the feature is complete you merge it back into your main branch, e.g. ‘trunk’ in Subversion. As you approach the deadline, e.g. the release date, you now have options. You can either ship with just the features that are complete or you wait until some or all of the remaining features are complete as well.

Of course this changes the scope of the release. However, if the features are worked on in their priority you may be able to ship the more important features even early or at least on time. This is sometimes a viable alternative to not shipping at all.

In the teams that I have worked with this approach is working quite well. There are a few more aspects to this but I’ll cover these in a future post.

Measuring Productivity of Software Engineering

Not too long ago I had a conversation with a friend and we discussed productivity in software engineering. In particular we got hung up on the question how to measure it.

It’s not that nobody had ever tried to measure it. I have probably about 30 to 40 books just on metrics alone. So far, however, I haven’t found a method that would meet my requirements. Let me explain.

Let’s assume you have a team that is working frantically and has a high productivity. Let’s further assume that you had a metric that can measure the productivity reliably. At some point the team ships the new system, not only on time but with a record breaking productivity maybe even ahead of time.

Enter the customer or even better the actual user. They sit in front of your brand new system. The initial comment: “This is not what I wanted. I don’t need a system for making hotel reservations I need a system that helps me control my production plan.” (OK, not a real case but I have to protect the innocent and I think it makes the point.)

In this scenario, what good is it if you have the best productivity on the planet if as a result you deliver the wrong features? Wouldn’t this indicate that in the end it is the customer who judges whether they get enough value for money? And wouldn’t that be a good metric for productivity? In this case, because the wrong system was delivered the “productivity” in terms of features with business value was zero. At least from this customers perspective.

In the discussion with my friend we really go stuck at some point. We had already agreed that counting lines of code (LOC) doesn’t help, or counting the number of classes, methods, function points, statements, screens, etc. Equally counting the hours doesn’t work.

My friend and I agreed on all of this. We couldn’t find a metric that we believed would work. Then I asked him how he measures productivity and his answer was: “gut feeling”. I’m not quite sure about his answer.

As for me I have decided that if several customers tell me that they believe they get good value for their money, e.g. for their maintenance fees, then I take that as a sign for a good productivity. Productivity measured as in business value perceived by the customer. Does that mean we now lean back and have a good time? No. We still use a continuous improvement process within our team to find even better ways of working, even more waste we can eliminate. And we continue to have a good time on top of the hard work!

Small Commits

Again and again I see example of why it pays off to have small commits. By that I mean something very practical, namely a commit to a version control system.

As I work through a story I don’t implement the entire story in one go. Instead I look for even smaller steps, ideally using tests to drive the development.

When I say small I mean more on the scale of every few minutes rather than maybe a couple times per day.

If something doesn’t work correctly I have only a very small number of places where to look for what is wrong. Most issues I find by just looking at the code changes. This works even better when I work with a programming partner.

As I find most issues by just looking at source code only rarely I need a debugger let alone stepping through vast amounts of code. This, too, is a time saver.

And in case I stuffed up the code completely I don’t lose much work, maybe just a few minutes, and I pull out all my code changes. Then I start from where I was just at the last commit. I continue from a known position.

The principle at work is small increments. This also applies to roadmaps, budget spreadsheets and other items. Just give it a try!

My recommendation: With commits you can’t err on the too small side!