10 Tips for Non-Technical People To Identify Amateur Development Teams
As a non-technical person have you ever wondered if your technical team is effective? Do you ask yourself if the speed of development and the number of bugs in your project are reasonable? Do you often doubt whether the team you are working with actually suits the needs of your project and should be trusted further?
In this post we present to you the symptoms of non-professional software development teams. The points we make have been discussed in the community for a long time and there are multiple sources that we will refer to. We will also add some ideas from the knowledge we have gathered from both working in different companies on different software projects and while being a company and working with multiple customers and other teams.
1. Recurring bugs
Recurring bugs are the ones that were once considered fixed but reappear in a later release. This usually happens if a newly implemented feature or a bug fix is somehow related to the area of the original bug. The reason for this phenomenon is related to the fact that while fixing the bug the engineer concentrated only on making the functionality work the way it is described in the expected result of the bug report. Instead, the responsible and professional developer would realize that there is a deeper logical or a code design issue and address it fundamentally.
2. Fixes to bugs cause others
This phenomenon is described by the term fragile code . The effect of this issue reveals itself when a change in the logic or the structure of the code causes an error in an unrelated area. This fix to this flaw usually involves a redesign of modules and their dependencies. However, a professional team realises the urgency of such redesigns and executes them in a timely manner after informing the management.
3. Simple features take much longer than planned
Another notion described in  is called code rigidity. The non-technical person can easily identify the existence of this issue when the developers end up spending much more time than they had estimated on a feature or a bug fix. The issue is related to poor dependency management of the modules commonly referred to as tight coupling, such that one change requires recursive changes in other modules. The fix for this is usually in the implementation of an appropriate architecture that minimizes unnecessary dependencies and forces the developers to not add complex interrelationships in the future.
4. Drastic slowdown of development
If during the development the time for implementing features of similar complexity increases progressively as described in the chart by Martin Fowler below, it is a good indication that the design of the code is not appropriate or has become inappropriate because of non-professional attitude or lack of knowledge of the development team.
Design Stamina Hypothesis by Martin Fowler 
An early indicator of this problem is that developers avoid working on different pieces of code saying that it is old and convoluted and that they are afraid that the changes will break the logic in unexpected places.
Usually, in such cases the management resorts to hiring more developers and pays more to recover the former pace. However, unless fundamental changes are made aimed at improving code quality, the money spent becomes money wasted.
We are aware of profitable projects that were rewritten from scratch after realizing that it was too late to fix the code structure to continue further development. There have been even completely failed ones just because of the code not being maintainable or extendible anymore.
5. No Pauses To Pay Large Chunks of Technical Debt
The above situation can be cured. It is referred to as paying the technical debt.
Technical debt is defined to be “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution” . The reasons that it exists and is accumulated over time include the uncertainty in the early stages of the project as well as the changes in the requirements during development and the effect they have on the structure of the code. Given the currently popular Agile methodology of software development, over time some features that were not considered when creating the fundamental architecture of the code can require huge changes to the overall structure of the code. For example, if in a platformer game initially there is only one player planned, the requirement to add another one can cause a lot of trouble for developers. For being able to deliver the feature on time some compromise has to be made between speed and quality, and instead of making fundamental changes to the architecture, some things are often just made to work. This is a typical situation for any team. However, subsequent features could include adding more and more functionality to the second player and more importantly to the ways the players interact with each other. Eventually, the symptoms described in the beginning will start to appear. This is the time when the professional team needs to convince the management to pause development and to allocate a significant amount of time towards refactoring. This should be done to make the architecture fit with the new core features.
6. No unit tests are written
Unit tests are a mechanism to automate the process of checking if individual parts of code perform as expected . These tests are developed or updated at the point when the unit is just created or modified and should be run regularly. Moreover, unit tests are the basis for a whole development process called test-driven development (TDD) .
Apart from the ability to maintain a working state of the software after each new feature and bug fix, unit tests are very helpful during code refactoring. In fact, without unit tests any deep refactoring becomes a nightmare for both the developers and the QA team. Especially if the regression tests are done manually, figuring out the scope of all the functionality that was in any way affected and covering it can be infeasible. Thus, usually in the projects without unit tests, the developers are very reluctant to do large refactorings. This leads to almost all of the above symptoms. Therefore, in projects where unit testing is conceptually possible, regardless of tough deadlines, the developers absolutely have to write unit tests and maintain and extend them as necessary.
7. No strict review processes are in place
No single developer can write perfect code. When some people review that code, the chances of not only fixing bugs but also minimizing the technical debt increase exponentially. However, the whole team needs to have the right mindset to make the reviews useful and actually serve a purpose. That mindset should revolve around the idea of leaving the campground cleaner than it was when entering it. This is also known as The Boy Scout Rule .
A usual excuse for not doing proper reviews or not addressing the reviewer comments are again related to deadlines. It is the team’s responsibility to once again balance speed and quality.
Code reviews also aid keeping all the team members’ knowledge of the code and general technical level balanced. This results in not having irreplaceable people which is of management’s best interest.
8. No mechanism for constant technical growth
A team that gathers knowledge and skills only by working on day to day tasks sooner or later will become stagnated. The developers will probably be very good at some tasks and be able to finish routine work very quickly. However, the flip side to this is that they will stop being used to challenges, and whenever presented with a task requiring a new skill, a struggle will begin. Thus, professional teams find ways for constant technical growth just like sportsmen do in their disciplines. In fact, a good analogy is comparing a taxi driver to a car racer: any 2 year racer will defeat a 20 year taxi driver.
9. Readiness to implement any feature
Usually when a team immediately starts to assure you that they will implement a feature when they just heard about it, it usually means that at least one of the following two statements is correct.
They do not thoroughly understand what is required and what it will take
They are sure they will find workarounds and make the feature look as if it works without ensuring quality
An alternative to this attitude is taking the time to investigate the requirements in detail, understanding what functional and non-functional changes need to be done to ensure quality, as well as informing the management about specific sub-features that will cost a lot of development effort and helping them prioritise the features in terms of cost/benefit ratio.
10. The team is just a group of people sitting together
The final symptom of a non-professional team we want to discuss is related to the team responsibility and team culture. If a group of people that claims be a team does not possess common ground on issues regarding quality, work ethics, responsibility, and efficient processes, expecting them to deliver a quality product and maintain it is barely reasonable. The whole idea of a team is in providing a service which is better than the combined result of the work each of the team members would do individually. Thus, a team needs to develop the ability to operate as a single unit and under strict technical and ethical norms as described in detail in .
Prototyping phase specifics
All the above said, we have to mention the fact that a professional development team should be able to create a prototype as quickly as possible. This is related to the fact that the management of a starting project needs to test the initial version of the product in terms of marketing. In the case of games that includes the core mechanics of the game which is just enough to gather feedback from playtesters. After the prototype is tested and the decision to start the development of the product is made, the code can be potentially written from scratch and even in a different language or using a different technology. Thus, as Martin Fowler’s diagram shows, it is acceptable to sacrifice code quality over speed during the infancy period of the project.
So far we have discussed how important the software quality is in the development and what can lack of it lead to. However, while striving for the ideal solutions, the developers need to find the balance between speed and quality. Surely, if the client loses thousands of dollars per hour because of a bug in the purchasing system, the highest priority is releasing a hotfix as soon as possible. On the other hand, had the code the necessary quality, the bug might have been avoided in the first place, or at least fixing it in a clean code would take much less than in a convoluted mess. Therefore, marketing and software quality decisions are equally important, and qualified and responsible development teams will help to find the right time and the resources needed to both large refactorings and dirty hot fixes.
Finding a professional development team is not an easy task for a non-technical manager. In this post we have provided several indicators of a team that lacks professional skills and attitude. We briefly described quantitative and qualitative measures used in the industry to evaluate code quality.
We wish you best of luck in your creative endeavours. May the professionalism be with you and your team!
Please ask your questions and share your experience in the comments below. Don’t forget to subscribe to our blog for more posts like this and Like our Facebook page. Our next post will focus on choosing the right team for your project. So stay tuned…
 R. C. Martin and M. Martin, Agile Principles, Patterns, and Practices in C#. Prentice-Hall PTR, 2007.
 M. Fowler, “bliki: DesignStaminaHypothesis,” martinfowler.com. [Online]. Available: https://martinfowler.com/bliki/DesignStaminaHypothesis.html. [Accessed: 02-Apr-2017].
 “What is Technical Debt? – Definition from Techopedia,” Techopedia.com. [Online]. Available: https://www.techopedia.com/definition/27913/technical-debt. [Accessed: 02-Apr-2017].
 D. Huizinga and A. Kolawa, Automated Defect Prevention: Best Practices in Software Management. John Wiley & Sons, 2007.
 K. Beck, Test-driven Development: By Example. Addison-Wesley Professional, 2003.
 R. C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship. Pearson Education, 2009.
 B. Singer, Rich Dad’s Advisors®: The ABC’s of Building a Business Team That Wins: The Invisible Code of Honor That Takes Ordinary People and Turns Them Into a Championship Team. Business Plus, 2006.
Vahagn Harutyunyan, Team Lead at Noor Games
Narek Aghekyan, CEO at Noor Games