13 signs your software project may be doomed

Every software project begins with fanfare and gleeful optimism. Even the smallest side hustle hacked together late at night is born of starry-eyed dreams. The team is convinced that with just a few lines of code and some open source libraries we’ll be done and accepting bonuses for our elegant, faultless work.

But then a few weeks or months in and we wake from our dreams to find git repositories filled with decisions and revisions and reversions. Is it good enough? Is it close enough to the specs? Will anyone actually use it? All too often software teams get deep into a project only to find at least some of the answers to these questions coming back as “no.” Is there any way to see it coming?

Sometimes, it’s true, the best laid programming plans go astray with no warnings, but more often than not, a doomed ending is all too obvious to anyone paying close attention along the way.

Here are a baker’s dozen early warning signs of likely software project failure.

Shifts in management support

Was the project’s champion arrested one morning after trying to get his or her kid into USC or Yale? Did the CIO cancel the last three progress review meetings? If you round off, has it been a year since you’ve seen the CIO? Has the CFO asked about your staff budget? Is a merger going to sweep out half of the org chart?

Many software projects fail for reasons that have nothing to do with the people writing the code. Someone in management loved your software project and championed it through approval processes, and if that someone disappears, support can crumble. It doesn’t matter how great your vision may be. If another party has a different vision for the company’s direction and that faction grabs control, your project may evaporate. So as much as you may not want to, pay attention to the politics.

Changes in the marketplace

It’s not just insider support that matters. Consumers and the marketplaces they drive can also shift their desires. Whereas software projects take months to complete, markets can evaporate in weeks, days or even minutes.

If your project is targeting a rapidly evolving market, the odds are higher that the marketplace will be entirely different by the time you’ve finished your code. Even if your project is dealing in a more established and stable field, new competition can appear almost overnight. If your team doesn’t have a plan for adapting to changing trends, the odds are good you’ll be gone.

Programmers jumping ship

People switch jobs all the time and good programmers are in high demand but if the team is constantly losing people then something is broken. If the salaries are high enough and the work conditions are generous, then the project itself may be to blame. Maybe the coders are flummoxed by the requirements and they jump to avoid the mental stress. Maybe the architecture is all wrong and they can’t make it work. Maybe there are some toxic personalities on the team that are driving everyone away. Team outflow is a good sign that something is awry that may undermine your project’s chances for success.

Simple things take too long

How quickly can the team respond to very simple changes? Can they change the background color? Move a checkbox over a few pixels? If the tiny change tickets aren’t getting processed quickly, the big changes are going to take even longer.

Sometimes bad architectural decisions will make some simple things close to impossible. One project I worked on asked me to fill one extra column in the database and this required changing five different microservices. That meant checking out five different projects, working through five different code reviews, and writing five different sets of unit tests. All to update one number in one row.

Developers have a way of overcomplicating the simplest changes and sometimes the cleverest developers are the worst. Some changes are going to be difficult, but if the team has trouble handling most of the small changes then it’s an indication that the foundation is too complex.

No cost model

It’s easier than ever to estimate what each user will cost. Cloud computers are available by the hour and serverless systems are priced by the transaction. If users are going to hit your server farms N times a month with M bytes of data, do you know how much it will cost to do all the computation on that data?

Some project teams don’t have a clue about costs and then they discover that a transaction that costs X pennies is making only Y pennies of revenue and, sadly, X > Y. The software may compile and run relatively bug-free, but the project dies because it’s a money-losing machine. Keeping track of the costs and having a firm target are essential or else the developers could end up building something that’s insanely cool but requires half a dozen of the fattest cloud machines around.

Developers continually defer to one genius

It’s nice to have smart people working on your project. The danger comes when one mind comes to dominate. Aside from a few weird cases, it’s generally a bad sign when everyone says, “Let’s go ask X” and X is always the same name. If X dies or runs off to find enlightenment in the mountains, the project can be rudderless.

If X doesn’t leave, though, it can be worse because everyone wants to run their decision by X and that bottleneck is stopping all of them from moving forward. X may enjoy the power and X may be a legit genius, but forcing all of the work to be approved by X is going to be slow.

Code standards dominate discussions

Aesthetics matter but some developers take this to the extreme by obsessing over the amount of white space in their code. So-called code standards are just one way poisonous team members can exert power. They announce ominously during code review that “standards aren’t being met” when they find a misplaced space or tab.

Functionality will ultimately make or break a project and if the team is off arguing about aesthetics of internal code that will never be seen by outsiders, well, the team may never reach the goal. 

Metrics look too good

Measuring team progress with metrics is a necessary evil but it’s dangerous to put too much faith in them because developers game whatever metrics you can imagine. One friend explained that his boss had a metric that measured the percentage of functions with comments and so he used the famous AI chatterbot Eliza to make sure that 100 percent of his functions had comments, no matter how inane. He even wrote some quick code to snarf the variable names and include them in the pointless comment. His stats were amazing. The boss who demanded all of the comments never read them and so the boss was never the wiser. He just saw a big 100 percent commented code on his dashboard and headed for the golf course.

Eyes drifting to the shiny and new

New languages, libraries and architectures are great but they have their place and that’s often not in a mission-critical stack. They’re fine for demonstrations and exploratory side projects. They’re okay for non-essential microservices on the periphery of the project. They’re maybe acceptable if the team has a comfortable timeline and they have no other choice.

The real tell, though, that’s hidden in the puppy love for some new software solution is the possibility that the developers are really struggling with the current project or architecture. The current plan may be producing too many glitches, bugs, and headaches. They may be trying to force some square-peg library to communicate with a round-hole API. There may be more glue code than real code. Dissatisfaction with the current approach may be leading the developers’ eyes to wander.

Unclear business specs

Is the vision for this process incredibly vague? Is it filled with buzzwords like “disrupt” or “meta” and not tech terms like “HTTP” or “AJAX”? Is there plenty of talk of “changing the world” and little talk of database choices or architectural strategies?

Creating software requires concrete technical decisions and sometimes the dreamers who imagine the project don’t spend enough time thinking about how this will work. Sometimes they’re lucky and someone clever is able to build it, but more often than not, unclear business specs result in failed projects. Maybe it will require too much bandwidth. Maybe the latency will make the user interface sluggish. Maybe the cost for all of those cloud machines won’t be covered by the advertising and subscription fees. We won’t know what will happen because the planning documents don’t get into that detail.

Uncontrolled complexity

Much of managing a software project is finding a way to keep users happy while reducing the complexity of the task to something that is manageable. Everyone wants the code to read their mind and deliver the answers effortlessly, something that is possible only when users all want the same thing.

Projects start to go awry when multiple factions start asking for different things. If they have too much power over the project and the project managers can’t find a way to align their interests and keep everyone happy, the project will become far too complex and the amount of code necessary to complete it will balloon considerably. If the project team can’t say “No” effectively, the complexity of the job will grow much faster than the programmers can write code.

Poor testing plan

Some programmers love to churn out new code. Each line is a real creation, an artistic statement about bits that will be transformed into some other collection of bits. Where there was once darkness, there is now light. It’s a wonderful feeling, but it’s only part of the picture. It’s not enough to build the software, we need to understand when it’s running correctly so we can understand when it’s failing.

A good testing plan looks backwards not forwards by checking to see that everything works. There’s no rush of excitement and thrill of conjuring something ex nihilo. It’s just full of nagging and reminders to go back and do it right this time. Testing isn’t pleasant.

But testing is as much an art as building the code. Too many tests and you’ll never be done. Too few and the code doesn’t work. If a software project team doesn’t balance the ecstasy of creation with the drudgework of testing, they’re headed for failure.

Unreasonable expectations

Some things are so easy with software that people running projects often don’t recognize how hard it can be to make this magic work. Many projects can compile and run with few errors, but if they don’t deliver what the audience wants, they’ll be seen as failures. Sometimes the problem isn’t with the code, it’s with the unmanageable dreams of the people who will use it. What? The new database is not curing my baldness too? I thought it was going to deliver teleportation just like Star Trek!

Software developers need to keep control of the project to ensure that bold dreamers or big thinkers don’t take control. If expectations are kept in check, a project has a chance to meet them. If they aren’t, well, not even the most wonderful, bug-free, low-latency, totally progressive app will seem like a terrible disappointment.