More People Won't Fix a Software Problem

Have you ever heard the phrase “money doesn’t fix money problems”? The crux of that statement is that if there is a fundamental problem with the management of money, pouring more money into the situation will simply extend the bad behavior. In my opinion, the same thing holds true when it comes to software and people.

The One-Month Baby Problem

You’ve got a rock star, ninja, 10x, unicorn developer. You need to replicate that person’s capability to push a project to a possibly unreal deadline. This is where we have the challenge of trying to solve a software or process problem with people. It rarely works.

I’m not saying that the software can replace the person, but what does work is when we spend time reducing technical debt to relieve the existing task wranglers of mundane work that uses the same amount of effort over and over again.

This is what Ii call the one-month baby problem. It takes nine months to make a baby (10 if you really count it out), and we all know that you can’t get nine women together and produce the baby in one month. That’s just a biological fact. Effort and result are not always correlated.

Systems Thinking: Software Approach

What is a task or process that you have that could be treated as a system?  You’ve probably got lots of tasks that are being performed all the time that you may not even realize are taking up so much of your day-to- day effort. Is the way to solve a two-hours-a-day task to hire someone to just do that two-hour task? No. The solution is to find a way to automate that task through software if possible.

If it isn’t possible, then we need to look at another constraint in your day-to-day process feeding that task or resulting from that task to look for a way to reduce or remove that constraint. Lather, rinse, repeat. We can use people to solve that challenge, but simply throwing more people at the tasks and then doing nothing to affect the way the task is handled is not the solution.

We can quote The Goal on this one. As noted by Eli Goldratt in his best-selling book:

Assuming the goal of a system has been articulated and its measurements defined, the steps are:

Identify the system’s constraint(s).

Decide how to exploit the system’s constraint(s).

Subordinate everything else to the above decision(s).

Elevate the system’s constraint(s).

Warning! If in the previous steps, a constraint has been broken, go back to step one, but do not allow inertia to cause a system’s constraint.

Challenges in the IT Infrastructure World

A rather biting piece was written about OpenStack by Canonical founder Mark Shuttleworth that details the difficulties of running the overall OpenStack project ecosystem. I call this one out because it refers to the staff reduction at HPE and at Mirantis. The issue of throwing more people at a problem that didn’t actually reduce the friction of deployment and adoption resulted in having to reduce the workforce size when profitability and results were called into question.

I’m a huge proponent for OpenStack. I also see the challenges around the ecosystem as it grows. Shuttleworth’s approach to the subject was a little brash for some, but the intent is good. We need to recognize where the wins are for automation and process improvement that can help move the overall ecosystem forward. As consumers of OpenStack, or any technology, we should always be looking for ways to leverage automation and process improvement to better use those technologies.

Take a little time each day and look for ways to do some technical debt reduction. It will win you back much more than hiring someone to just do that thing for you, causing you to have two problems: the original problem and a staffing cost issue.