When you start working on a project, there is one thing you can be absolutely certain about – your final product won’t be flawless. No matter how hard you try, regardless of the time you spend on analysis, of your technical expertise, and of the number of tests you've performed, there will always be room left for deficiencies, or, as we call them in software development, bugs.
It is not surprising that, when the final product contains a small number of bugs, we need to take a closer look at it and see what led to such good results. In this article, we will study a small project that fits this description and that was completed with no more than two bugs.
Team Compatibility / Communication
When we talk about team compatibility, we usually think about the development team. However, what made this project so successful was the compatibility that spanned all the way to the Client and to Project Management. Starting from the first meeting with the Client, you could feel that the atmosphere was relaxed, without lacking professionalism. The communication was open and transparent, and from the start, it felt like we already knew each other well. When the meeting was done, we all agreed that it went much better than expected; you could tell that everyone was anxious to start working on the project.
During the project, we often had casual ‘coffee’ meetings where we discussed the project’s status. Moreover, although at the very start of the project we stuck to a certain ‘communication hierarchy’, we soon realized that communication may as well be looser and more relaxed. When you create a friendly relationship within the team, nobody is afraid to ask questions and speak openly about problems. This is crucial in reducing misunderstandings and potential bugs.
Project Specification
Before the project had even started, the Client already had a complete project specification that was given to our development team. This specification was very detailed, containing examples and templates that we were supposed to implement. This made the whole process much easier and errorproof. A deficient or incomplete specification is often the cause of many last-minute change requests that have a high probability of generating bugs – which wasn’t the case on our project.
Technical Support from Client
During the project lifecycle, there was a technical expert present on the Client side, available at our disposal. Every time we had questions regarding technical implementation or uncertainties regarding the specification, we could contact him and he would provide us with answers. He had high technical knowledge and was able to understand our issues and the suggestions we offered. His competence assured that our development was always heading in the right direction, and it minimized the chance of additional changes that might appear later during the project.
Proactivity and Creativity
One of the most important things a development team should have is creative thinking. They shouldn’t blindly follow specifications and defined tasks; they should instead think about new and better ways to do something. In doing so, you not only get a better product, but you also encourage developers to be involved in the thinking process that increases their focus and concentration, reducing chances of eventually creating faulty code. In our project, we had developers with their own ideas and suggestions that were often praised and approved by the Client.
Also, when faced with questions regarding business logic, we used the in-house knowledge we had about the topic. One of our developers went to the company’s accounting office to get informed about the accounting terms needed for understanding the business requirements.
This might seem insignificant, but it is small things like these that make a difference and contribute to fewer errors and bugs in the final product.
Project duration / Complexity
When talking about the number of bugs you deliver in the final product, one must not ignore the project’s complexity. Bigger and more complex projects include a large number of people, more complex documentation, more complicated problems, etc. This basically means that more things need to be done – which is in direct correlation with the number of bugs you may generate.
Simpler and smaller projects are usually made up of simple tasks, so bugs are less likely to occur and it takes less effort for the project to be completed with a small number of bugs.
Conclusion
Everything mentioned above played a crucial role in delivering an application that contained only two bugs. As you can see, many things need to fall into place in order to deliver an application that contains so few bugs. We may impact some things, but not others, however, it’s projects like these that remind us that, if things are done right and if the working environment is healthy, it is possible to produce a high-quality product with just a few minor deficiencies.
