Take Your Time, It's Faster

I've been a software developer for about a decade now. I've worked my way up to a team lead position and delivered quite a few projects, with a couple of really big ones recently. These recent ones had mixed levels of success, depending upon how success of IT projects is measured. From these projects, I've learned some things, which I'm going to share now.

Success is not what you have been told

Traditionally, in software-based degrees, you are taught that success in IT projects comes down to 4 core success factors:

1. Was it on time?
2. Was it under budget?
3. Did it meet the requirements?
4. Was the quality acceptable?

And these 4 things are aggregated into an overall: Was the client happy?

What I have learned is that, time and budget often only matter in the initial phase, when a project is being assessed for development-worthiness. This generally means a cost-benefit analysis is done on optimistic projections using super-high-level development estimates, to which the developers have not committed. The project stakeholders want their project approved, so they'll do whatever it takes to make sure the numbers work out. Once the project is approved, it doesn't matter whether the time and budget blow out, so long as enough progress is being made and shown to indicate that the project will be completed at some point that doesn't seem too far off.

I'm not saying that this is the way that things should be, merely that this is how things often turn out.

Once time-lines start getting stretched, there are common 3 mitigations, assuming the project isn't going to get cancelled:

1. Cut scope - This is what "agile" teams would tend to do. It affects success factor 3, but allows a product to still be released without much delay. I say "much" because there is often work involved in hiding or removing the in-progress work that doesn't make the cut. When cutting scope, if a stretched time-line starts to look comfortable again, then there is often pressure to add more functionality, with the reason for removing scope in the first place being forgotten.
2. Add more developers - This is the classic Brookes' Law reaction. There are right ways to do this, and wrong ways. If work can be partitioned without too much interaction between developers, then it can work. For example, if there is clear delineation between front-end and business logic, then the front-end can be given to a developer with mock-ups to work from. This decision must be closely monitored, or the problems will be exacerbated. Leading a growing number of developers can itself lead to issues that reduce quality in other areas.
3. Allow more time - This allows the existing plan to still be implemented, but other projects get delayed for lack of developers. Running overtime also means that the budget has blown out, as the developers' time is costly. This affects success factors 1 and 2, but is the only option that doesn't affect factor 4. Unfortunately, this is usually the choice that occurs after options 1 and 2 have already been tried, and like with cutting scope, other work tends to slip in, so allowing more time ends up leading to a modified set of functionality, implemented by a large team, taking longer than forecast.

Even if a different product is delivered compared to what was required, and it runs late and over budget, and it has "teething" problems, once it is out, if it does enough to be useful and brings in good money, then stakeholders will be generally happy and consider the project a success.

Another way

These experiences, and my pre-existing tendencies, have led me to this conclusion that if you have the right people and plan for the smallest iterations, then there is some amount of time that it will take, which will only be truly discovered by doing it and seeing it through.

To expand on this, what I mean is that cutting scope is problematic. So if a phase of a project can be delivered without a piece of functionality, i.e., if you could ever consider cutting it, then move it to "phase 2". Just don't put it in the current phase. Keep the amount of functionality as small as possible while still delivering value.

Then, if you've got the right people working on the project, both in the trenches and on the supply lines, then there is probably nothing that you can do to affect the reality of how long the project will take. So make your high-level estimates, but pad the hell out of them so that they are adequate even if there are big delays. If the project is still appealing, go ahead with it, and just accept that it will be done when it's done. Anything that's borderline probably shouldn't be getting done anyway. The estimates won't look so good to the stakeholders, but it is far better to deliver early and get started on the next project than to run late and have all the problems mentioned above.

The reason why I am so adamant that projects should contain the minimum feature-set possible, and plenty of time in which to implement them, is because any of the mitigations listed above lead to lower-quality work, that will just come back to bite later. All 3 mitigations only happen after there has been a lot of effort to squeeze the development into too small a schedule. This means short-cuts have already been taken by the time the time-line has slipped. A bad design here, a hack to get something to work there. Before you know it, you're given all this extra time, and you realise that you have 2 choices:

1. Do it properly, removing the hacks and redesigning the rushed parts. This takes even more time, leading to a vicious cycle.
2. Get the project out as quickly as possible, which means layering hacks upon hacks. This is a false economy, because developing on a hacky system takes more time, and is more prone to break.

You can't argue with reality, so you just have to embrace it. The earlier you embrace it, the less time you throw away doing the wrong things.

Despite being a total nerd who has been in the industry a while, this is the first time I've actually written about software development, so let me know your thoughts.