Ruminations on The Development Process – Part 3

If you hadn’t noticed, we launched a new version of the application on the first of July 2016. Macrobond 1.16. You can read about it here if you want to catch up on all the new features that were added. In light of this I want to write about what goes into the planning of a new version. A bit of a behind the scenes view, so to speak. Why do some things get added and others don’t? And how do we decide?

The Basics

The first thing you should know is that we have a very long list of things that we would like to add to our product. And new things are added to that list all the time. There are many reasons why we can’t just do them all at once.

One obvious reason is resources.

Developing a product is expensive. It doesn’t scale very well. If you double the number of people working on a software project, you are very lucky if you speed things up by 50%. It is kind of logarithmic with quickly diminishing returns on the investment.

Adding a basic version of a feature first in order to get feedback from the users.

We use this well proven strategy before taking the next step. But for this to work, things need to sink in. If we rush ahead too quickly, we might end up moving in the wrong direction.

Changing the product too quickly puts a strain on the users.

Users need to be educated and learn to use the new features. Some users like new things; others hate when things are changed.

Long term planning – rarely works

Things are changing all the time. So are priorities. Over the years I have spent countless hours making long term plans and doing detailed time estimates. This has been a waste of time. Long term plans never hold. New things come up and priorities change before the full plan is executed. If you choose to ignore this and stick to the original plan, you end up with an inferior product. If you abandon the plan you have wasted all that time planning and there is always someone who expects you to deliver. And to deliver on time.

Time estimates – rarely work

Even if you make it very clear that the time estimates are very uncertain, they still tend to be taken as a promise, and there is always someone who is upset by the “delay”.

What about making a good time estimate? Very time consuming. And you really have to dig into the details in order to make even a fairly rough estimate. Essentially, to make a perfect time estimate, you might need to spend as much or more time on the estimate as on the implementation. The effect is that you have moved the uncertainty of how long it takes to implement a feature from the implementation phase to the planning.

What will you add next year? – I am proud to say, I don’t know!

This is how we do it:

  • We aim to deliver a new version every 3-5 months.
  • When we have implemented all the features for a new version we let internal and beta testers use it for 1-2 weeks in a final test phase. From then on we will only work on bug fixes.
  • During the final test phase, we take a look at our long list of things we would like add to the next version of the product and pick some things from the list that we think would take 3-5 months to implement.

We often implement a basic version of a feature in a given version, and then refine it in future versions. That way we get feedback before taking the next step, which results in a better product.

Taking things as they come

It does happen that our time estimates are completely wrong. If things are easier to implement, and so take less time, we consider adding more things to that version. If things take a much longer time, we can either postpone that version, add the feature to the next version or, in the worst case, skip it altogether.

This approach gives us a lot of flexibility to adapt our development to changing conditions. It also makes it possible to respond quickly to new important requirements. If we implement complex features in several smaller steps, it gives us an opportunity get feedback. Taking on shorter projects also works better for most people. It makes it possible to focus hard on something for a few months and then take a breath before you move on to something new. Some things we do might be rocket science. But we are not building a rocket to the moon with an absolute deadline, where work on the project is complete when it is launched. We are in this for a long time!

So, what’s the catch?

One drawback is that we cannot provide a long term roadmap. We certainly have some long term ideas about the direction in which we’re heading, but we do not know how long it takes to get there. My experience is that most long term ideas will never be realized because they are out of fashion, priorities change, and other things become more important.

For this reason, we don’t communicate our long term ideas. Because if we do, we cannot be as flexible as we need to be. Even if they are just ideas, there would be pressure to deliver.

How do we decide which features to add next?

We look at a number of factors when we decide what things to attempt to do in the next version.

  • The priority we get from customer feedback.
  • The amount of time it takes to build something.
  • Looking forward.
    We try to add features that no one has asked for, but that we think would be useful for many users.
  • Developer resources.
    Some of us are better at certain things. There can also be conflicts if several developers work on the same “area” of the application.
  • Interdependencies.
    Interdependencies require building one feature before we can build another feature with a higher priority. There might also be dependencies on other parts of our IT infrastructure or data that must be in place before we can do our part.
  • Technical requirements.
    Sometimes we need to adapt to new technical requirements, such as new versions of Windows or Office.
  • Diversity.
    It’s preferable to try and include some improvements in all of the main areas of the application for most versions. For instance, we may try to improve charting functionalities in each version.
  • Housekeeping and maintenance.
    Every now and then we need to replace parts of the internal plumbing in the application just in order to have a solid foundation to build on in the future.
  • Fun.
    I must admit that there have been cases where we have done some things just because they are more fun to build than some other thing.

Now I need to stop writing! We have a new version to plan and I need to do some real work.

Scroll to top
Thank you! Your subscription has been confirmed. You'll hear from us soon.
Subscribe to our latest posts