Controlling developer risk

Managing software projects is not easy work, but once every while you do get a break. As the gods would have it, this was my day. Everything was going swimmingly well, we just had a couple of bugs to close before the client demo next week. The developer on the team was a solid engineer, his code quality said so.

On this particular day we were having our final review. 5 minutes into it, the developer is not yet in, no worries. 15 minutes later he is still not in, try to call him he doesn’t pick up. We suspend the meeting to the afternoon in the hopes that he will show up. Afternoon comes nothing, evening nothing. The developer goes on to disappear for the entire week, picking up only once to say “I will call you back”. The call never came.

In a previous entry I talked about Hidden risks to project success. Today I will expound on the biggest risk of all, human failure.

Paradoxical relationship between money and motivation

Developers for most part are self motivated individuals. In your hiring process you maybe shocked to find someone who has written multiple open source software, put products in the market and contributed to their community.

It easy to conclude that if they could do all that for free, then imagine what more they could do for money!

Unfortunately this conclusion is wrong. Somehow when you pay the dev to do the work they were previously happy to do for free, the magic disappears. I wish I had a cookie cutter solution for this phenomena. Still I have learnt if you can somehow find a way to give authority back to the devs, the results can be amazing.

Here of course I assume you are paying your developers reasonable rates.

Ineffective management

The field of project management has matured and is now a degree course. As it turns out, your PMP certification does nothing to prepare you to manage a software project.

It is said you can learn more from one failed software project than an entire lifetime in any other field. Software presents challenges that no other project presents. If I had to narrow it down to just one factor. I would have to say it’s the fact that the design is the product. To understand the gravity of this concept, imagine a building project. First the architect draws up the plan, then the builders get to it and get the building done. If the design is successful then future builders can reuse the design to build a new building. In short the work can now move to refining the process by which design is converted to product.

In software once the code is written the only work to be done is to compile it. Every new piece of software represents new design. The elements that can be reused are at best libraries.

This means as the project manager you have to deal with design problems and risks that are novel each and every time.

Unless the project manager understands this fundamental concept, they will continue with hacks that worked in the past such as:

  • Adding more people to the project late to get it done faster
  • Overly detailed project plans featuring Gantt charts, CPMs that are accurate to the hour
  • Encourage Code like hell mentality

This tactics slowly kill the project from the inside out.


There is no single factor that would give you assurance of the quality of your hire.

  • Not their contribution to open source
  • Not glowing reviews from past clients
  • Not even a previously successful project!

The reality is you will eventually make a terrible hire. When that does happen the results can be disastrous. You will see it in poor designs, increased rework and communication break down.

Hiring them in the first place can be forgiven, what can not be forgiven is keeping them on the team. The rest of the team will degenerate in performance to match the poorest performer, do not assume that the new hire will be the one to catch up.

Ramp up time

When a dev gets into her flow, everything is magic. She merely needs to touch the computer and quality code practically writes itself.

Before this magic moment, there is time they just don’t understand what is going on. This is especially evident when you drop in a dev to an existing project.

It may take a few minutes to understand a concept note, but it takes days or even weeks to grasp the technical requirements that will bring that concept to life. Give your developer the time she needs to acclimatize herself to the project. Factor in that time when planning the project.

What are some of the personnel issues you have run into when running software projects?


Published by


API Engineer