Developing Software, the Right Way

Geert Konijnendijk on 01/17/20 Behind the Team

Developing software is hard. The majority of large software projects run over budget, over schedule and do not deliver the expected benefits. While small projects are significantly more successful (up to 61% according to the Standish Group) they still fail often. What are the causes behind this and can you do anything to increase the success rate of your project?

Developing Software, the Right Way

It turns out there are steps you can undertake as a company to mitigate common causes of software project failure. Some of them are purely technical, but most involve human and communication components. Below is a high level overview of common problems you could encounter during your software project, including hints on possible solutions.


Problem: Users are giving negative feedback or no feedback on new features.

Developers must always strive to develop an application delivering the most value possible for end users (given constraints like budget and time). In some cases, a project is steered according to what stakeholders or developers think users need, as opposed to what users actually need. In that case the project is almost certainly moving in the wrong direction. Developers might develop features that are over-engineered or undercooked. Or in the worst case: features no user wants.

Solution: The development team can be a great asset in figuring out what users want. They are the ones who are already developing and monitoring their application. When given the freedom to collect data from the application, run experiments and act accordingly, great things will happen. Most importantly, the team will provide you with insights from users, which help focus on the wildly important and help deliver as expected. As another likely result, the development team will feel more involved, which will improve their motivation and the end result.


Problem: Development takes unexpectedly long or the results are underwhelming.

Sometimes, developers overpromise on what can technically be achieved. Causes could include a lack of crucial information on the project or unexpected delays.

Other times, stakeholders in a software project might not have deep technical knowledge, making it more challenging for developers and stakeholders to communicate. This may lead stakeholders to expect more results than developers are able to achieve in a given time or within a given budget, through no immediate fault of either party.

Solution: First of all, there should be a culture of openness and honesty between stakeholders and developers. When both can share their current issues with each other, they will be more aligned and misunderstandings are less likely. Next, stakeholders should check in with developers regularly. They could share new insights from customers or other subjects relevant to the project. This will keep stakeholders involved and updated about development progress and keep developers  committed and involved with the project as a whole.


Problem: The developed software is brittle and buggy.

When software is not tested, poorly tested, or not tested at regular intervals, development velocity will soon be impacted. New features might not work as expected. And even worse: new code is likely to break already existing functionality.

Solution: Developers should write automated tests. When written well, these will verify the correctness of separate code units and the correct interaction of these units in the system as a whole. Because these tests are run regularly and automatically, they will give developers confidence that their new code does not break any previous features.

Writing automated tests will come with startup costs, but will quickly pay out in sustained development velocity.


Problem: New features become increasingly harder and more time consuming to implement.

High quality code should be well structured and documented. This increases the likelihood that future programmers are able to understand code written by others. Since coding is a collaborative enterprise, understandability is key to keep code suitable for further development.

If, on the other hand, code is of low quality, it is hard to understand and more likely to contain bugs and security flaws.

Solution: Just like automated tests, automated checks on code quality should be run. Tools like SonarQube can integrate with build infrastructure and block the integration of any code that does not adhere to quality standards. These checks are easy to setup and their suggestions are often quick to implement. Running code quality analysis is a straightforward decision.

These kinds of code analysis tools can spot poor quality code and common mistakes. Unfortunately, passing analysis does not immediately mean high quality code. In addition to code analysis developers will need to peer review each other’s code to find low quality, buggy or otherwise flawed code that automated tools could not catch. This is a more involved and time consuming process than setting up automated code quality checks. However, it is one that is certain to pay off: code will be of higher quality, have fewer bugs and reviewers will have a better understanding of others' code.


The problems discussed here are just the tip of the iceberg of possible reasons a software project sinks. Many others could pave the way to failure, like: no support from management, using technology that’s either too new or too old or an inexperienced software team. We might not be able to foresee all possible problems that arise. However, when a software project sports skilled developers who communicate well with stakeholders and users the chance of success is already much higher.