Software Project Failure

I’m on a roll with the LinkedIn rants today 🙂

Do software development efforts fail because: 1) the technical staff is not skilled enough for the work, 2) management has unrealistic expectations, 3) lack of reasonable resources to perform the effort. I would be interested to know your thoughts.

Someone once said that failure can only occur when time and resources are limiting factors. In the case of software, all of the above are true, though the most consistent cause I see is that the process of doing the following in order:
1) Set a completion date
2) Define the requirements
3) Design the software
4) Develop the software
5) Change the requirements
6) Wonder what went wrong

Agile is a good step in preventing failure from the above process except that even shops that use Agile often face that the end date is set before work begins and that unrealistic expectations are set at the same time.

Another ongoing issue is that management’s reaction to bad news about meeting functionality or a date is to throw more people on the project and demand more frequent meetings which pull the people most capable of solving the issue away from solving the issue. This trains developers to not communicate issues until the last minute, which accelerates this vicious cycle.

As Dennis Miller used to say “But that’s just my opinion. I could be wrong”

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Developing Software in a Sauna

There are cynics amongst us (if you are reading this, you should know that by now) who say that the most pleasurable part of a sauna is getting out of it and being relieved from the heat.

Developing software is like that, sometimes. You will always run across a bug in your software, or poor documentation, or an upgrade or language shift where all the things you expect to be there aren’t. So you bang your head against the wall until a solution falls out of it (hopefully out of your head… though the wall has contributed on occasion). And then you stop banging your head and give it a final slap as you solve the problem. Then it feels good. So good, you wind up banging your head again in a few months/days/hours over another problem.

Of course, just like in the sauna, there’s always that one person who claims to love the heat—the developer who insists they thrive on chaos, who grins at a stack trace like it’s a Sudoku puzzle. Don’t trust them. They’re probably the same people who say they enjoy cold showers and anchovies on pizza. For the rest of us, the cycle is familiar: you dive into the code, confident and optimistic, only to find yourself sweating bullets as you try to decipher what “SyntaxError: Unexpected Token” actually means this time.

Eventually, after spilling enough sweat and coffee onto your keyboard to be justify the $10 spent on a silicone keyboard cover, you emerge victorious. The bug is fixed, the unit tests pass, your CD pipeline deploys to staging, and you feel a rush of euphoria that’s almost worth the ordeal. You promise yourself you’ll document everything this time, or maybe even write better tests next time. But let’s be honest, you’ll be back in the sauna soon enough—sweating, swearing, and secretly loving the moment when you finally get to step out into the cool air of a solved problem.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson