Why Software Development Projects Fail
This is more than just a list of cautionary tales.
Working backward from a failure scenario can help you increase the chance of a successful project.
What is a failure in software development
There are many ways to define failure when it comes to software development projects:
- The software is delayed.
- The project goes way beyond its budget.
- New features fail to meet business goals.
- New features affect the stability of the entire software system.
Mistakes in software development projects are likely to fall into two main categories: technical and organizational.
Technical Causes of Project Failures
Technical failures are on the "coding side" of development. It involves:
Architecture design
Often, architecture design is overlooked because of a myopic focus on which technology stack to use.
A tech stack can be an important factor in the success of a project.
For example, smaller projects like building an MVP can benefit from using more succinct languages like Python and Ruby. Bigger, continuous projects are better off using more mature programming languages like Java.
More mature technologies have more tools like bug tracking and continuous integration. They also have more community support.
But tech stack is only one side of the picture.
Architecture design is more important than choosing the right programming language. It defines how easy it is to change technology stacks or roll out upgrades.
The two most common architecture designs are monolithic and microservices.
What is microservice architecture?
In microservice architecture an app is built using services that interact with each other (A service is software that performs automated tasks based on what it "hears" from the hardware or other software).
A microservice architecture is better suited for big projects where changes are expected to happen frequently.
What is monolithic architecture"
The opposite architectural pattern of microservices is monolithic. Although it has worked for traditional, less complex applications, it can be a problem for modern applications.
It presents some potential problems: It can be difficult to make frequent deployments because you'll need to redeploy the entire application to update any component. Big chunks of code can be intimidating to work for developers.
This doesn't mean that monolithic architecture is a wrong choice by default. Netflix and Amazon were both initially built in a monolithic architecture. As both platforms grew and changes became more frequent, the switch to microservices became inevitable.
The bottom line: the choice between monolithic and microservices depends on the context in which your software is being built.
Poor test coverage
Often, testing is sacrificed when the pressure to release code becomes overbearing.
Time constraints can pressure a software team to cut corners on its testing. An infamous example happened in 2019, when Spanish bank TSB migrated to a new platform without thorough testing.
To meet a hard deadline, TSB's IT team tested only one of the two data centers they used for the migration. This decision caused 1.9 million of their customers to be locked out of their accounts.
An approach like test-driven development can nullify the risk of poor testing. If nothing else, the testing phase should be at the core of any approach to software development.
Not performing the necessary A/B Testing
A/B testing eliminates the guesswork out of choosing the better version of your website or application.
In worse scenarios, not doing split testing can affect your bottom line. Case in point: Etsy from way back.
In 2013, Etsy decided to implement infinite scrolling since it worked so well on Twitter and Facebook.
The company invested money to:
Build the feature. Fix the bugs. Do tests to make sure infinite scrolling works.
They did all the technical testing right, but they failed to test one thing:
They failed to test their assumption that infinite scrolling will increase conversions.
Customers were overwhelmed by the infinite choices that infinite scrolling brought. Site visitors also got lost at the length of the page--they couldn't find an item that they previously saw and liked.
Unclear rollback strategy
Deploying features will not always go smoothly. An undetected bug might be released into production. A new feature causes other features to behave erratically.
A clear deployment plan to roll out features into pre-production and production environments minimizes such risks.
When deployment goes south, a rollback strategy reduces the effort of developers to revert code to its previous state.
A rollback plan is a document that outlines all the steps, scripts, databases, and people needed to bring the application back to its previous working state.
Assuming that deployments will always go well is how lots of money and time is wasted.
Organizational Causes of Project Failures
Organizational failures are on the "management side" of software development. It involves making decisions on the type of project management system to use, deadlines, personnel, and budget.
Poor project management
According to veteran software developer Joe Kunk,
Developer mistakes are relatively easy to remedy compared to poor planning, a lack of leadership, bad estimates, or the impact of unanticipated risks.
Time pressure
Time pressure happens when a software team feels that there is not enough time to meet the demand of a task.
Often this happens because:
- The changes in requirements were not anticipated.
- A developer quits for another job.
- Some key factors in development were not accounted for in the planning such as: environment set-up, writing test cases, version control strategies.
- The deadlines are way too optimistic, ignoring possible pitfalls or problems during production.
All these factors are likely to be resolved by a good project management strategy.
Unrealistic budget
Money makes deciding a lot easier. With a bigger budget, you can hire all the developers and buy all the hardware and software you need.
With a limited budget, the two most common approaches you can take are:
Give up some of the features that you want for your software; or
Hire less experienced developers.
A third option is to outsource your software development. Outsourcing software development may solve your budget problems but it does open a new risk: hiring an incompetent software company.
Use independent review aggregators to mitigate the risk of choosing the wrong company to outsource to.
Increasing the number of developers to meet a tight deadline
When the nature of work allows people to work independently without the need to communicate, it makes sense that more people lead to faster work.
That's not the case with software development.
In the book, The Mythical Man-Month, Fred Brooks wrote that:
"Adding manpower to a late software project makes it later."
These are the reasons why:
- It makes a project more costly.
- It increases the chance of misunderstanding and unclear communication.
- More time and energy are needed to ensure clear communication.
- Extra time is needed to bring new team members up to speed.
- It takes time for new members to be productive.
Conclusion
All the risks in software development can be addressed by one crucial step: planning. The product owner, chief technology officer (CTO), project manager, and development team can work together to plan against failure scenarios.
Are you building a software product? Would you like to know more about our software development strategies? Schedule a call with our CTO.
