Ten Signs Your Software Project Is About To Take a Wrong Turn

Software projects can crash before you know it. Here are clear signs that your latest app development initiative isn’t as successful as it sounds.

Every software project starts with fanfare and joyful optimism. 

“Even the smallest side hustle hacked together late at night is born of starry-eyed dreams,” says Peter Wayner of CIO.com.

The team is convinced that just a few lines of code and several open-source libraries can help get the job done and result in a flawless application.

But then, a few weeks or months later, it wakes up from dreams and starts leveraging Git repositories already filled with solutions and revisions.

Sometimes, it is true, the most elaborate programming plans go astray without any warning signs, but more often than not, the doomed end is all too obvious for anyone watching closely.

Here are a handful of early warnings about the likely failure of your software project down the road.

1. Changes in management support

Many software development projects fail for reasons that have nothing to do with coding. Let’s imagine someone from the C-Suite loves your software project and supports it through approval processes and despite resistance from other stakeholders. But all of a sudden, this someone disappears (e.g., gets fired, leaves for a different company, retires, etc.), and so does the support. 

It doesn’t matter how big your vision is. If other stakeholders have a different vision of where the company should be heading and if they take control of the situation, your project may be suspended, cancelled or pivoted. So no matter if you like it nor not, always mind the politics and hidden agenda when it comes to shifts in management support.

2. Market changes

It’s not just internal support that matters. The consumers and the markets they control can also change their desires. While software projects take months to complete, markets can disappear in weeks, days, or even minutes.

“If your project is focused on a fast-growing market, the odds are high that this market will be completely different by the time you’ve finished writing your code. Even if you work in a more established and stable area, there’s always a risk of new competitors or force majeure like the Coronavirus. If your team doesn’t have a plan to adapt to changing trends, the chances are good that you will fail,” says Colette Wyatt, CEO of Evolve, a UK-based software house specialised in bespoke software development.

3. Staff attrition 

People change jobs all the time, and good programmers are in high demand, but if a team continually loses people, something breaks. If the salaries are high and the working conditions are great, then the project is to blame. Maybe programmers are confused by the requirements and jump to avoid psychological stress. Perhaps the architecture is wrong, and they can’t make it work. Maybe there are some toxic personalities in the team who drive everyone away. Team churn is a good sign that something is wrong that could jeopardize your project’s chances of success.

4. Simple things take a while to complete

How quickly can a team respond to very simple changes? Can they easily change the background colour or move checkbox a few pixels? If tiny change tickets aren’t processed quickly, significant changes will take even longer.

Sometimes bad architectural decisions make some simple things nearly impossible. 

For instance, some time ago, Evolve got a failing project that the customer backsourced from a different third-party provider it wasn’t happy with. 

In the process of project transfer, Evolve’s Tech Lead asked that third party’s software developer to populate just one additional column in the database. It turned out this task required changing five different microservices. It means that five different projects were to be tested; five different code reviews had to be performed, and five different sets of unit tests had to be generated — all to update just one number in one line.

Some developers have the habit of complicating the simplest changes, and sometimes the smartest developers turn out to be the worst.

Some changes can be large and tricky, but if a team has trouble handling most of the small changes, it’s an early sign that the foundation is too complicated and cumbersome.

5. No cost model

It’s easier than ever to estimate how much each user will cost. Cloud computing is available on an hourly basis, and the cost of serverless systems depends on the transaction. If users are going to access your server N times a month with M bytes of data, do you know how much it will cost to perform all the calculations on that data?

Some design teams are unaware of the costs and then find that a transaction that costs X penny only generates Y penny in revenue and, unfortunately, X> Y. The software can compile and run relatively error-free, but the project dies because this is a losing car. It’s crucial to track costs and have a tangible goal. Otherwise, developers might create something insanely cool, but it will take half a dozen of the most powerful Cloud machines to work well.

6. Developers continuously rely on one “genius” on the Team

It’s nice when smart people work on your project. The danger comes when one mind dominates. Except for a few odd cases, this is usually a bad sign when everyone says, “Let’s go ask X,” and X’s name is always the same. If X dies or flees to the mountains in search of enlightenment, the project may be ruled out.

However, if X doesn’t go away, it might be worse, because everyone wants to fulfil their solution with X, and this bottleneck prevents them from moving forward. X may be powerful, and X may be a genius, but getting X to oversee and approve the entire work will be slow.

7. Coding standards dominate Team discussions

Aesthetics matter, but some developers take it to the extreme by obsessing over the amount of white space in their code. So-called code standards are just some of the ways of how venomous team members can exercise power. During code review, they ominously declare “standards not being followed” when they find an inappropriate place or tab.

The functionality will ultimately make or break the project, and if the team doesn’t argue about the aesthetics of internal code that will never be seen by outsiders, well, the team may never reach the goal.

8. Unclear and unstructured technical requirements specifications

Is the vision of this process incredibly vague? Is it filled with buzzwords like “disruptive” or “meta” rather than technical terms like “HTTP” or “AJAX”? Is there much talk about “changing the world” and little about database choice or architectural strategies?

Building software requires specific technical solutions, and sometimes the dreamers submitting a project don’t spend enough time thinking about how it will work. 

Sometimes they get lucky, and someone smart can build it, but more often than not, fuzzy technical specifications lead to projects failures. This may require too much bandwidth. The user interface may be slow due to latency. Perhaps the cost of all these cloud services will not be covered by advertising and subscription fees. We don’t know what will happen because these details are missing from the planning documentation.

9. The metrics look too good

Measuring the progress of a team using metrics is a necessary evil, but believing in them too much can lead your project to take a wrong turn. One of my friends told a story of his boss being obsessed about a metric that measures the percentage of features with comments. To make sure 100% of his features have comments, even the meaningless ones, my friend used Eliza, a famous AI and natural language processing (NLP) tool.

He even wrote a little piece of code to intercept variable names and include them in pointless comments. His statistics were amazing. The irony is that the boss who demanded all of those comments never read them: he just saw a massive 100% commented code on his dashboard and headed for the golf course.

10. Weak QA and testing strategy

Some programmers like to write new code. Each line is a real creation, an artistic statement of the bits to be converted to some other set of bits. Where there was once darkness, there is now light. It’s a great feeling, but it’s only part of the picture. It’s not enough to make software; we need to understand when it works correctly so that we can understand when it fails.

A good test plan looks backwards, not forward, to see if everything works. There is no rush of excitement and thrill from creating something ex nihilo. It’s just full of whining and reminders to go back and get it right this time. Testing is unpleasant but crucial for any software success!

Final Thoughts

If your software development expectations always remain under control, the project has a chance to meet them and turn out to be a big success. If this is not the case, then even the most awesome, error-free, and low-latency application can become a huge disappointment and a waste of time and money.

Stay tuned with Software Focus!