Are Your Developers Costing You Money? Here’s How to Tell
Hiring software developers is costly. But do you know what’s more expensive? Hiring bad ones. There’s a marked difference in the quality of work between bad developers and good ones. The worst ones will cost you more money than you’d expect. How so? One way of putting it is that it’s hard to replace bad developers, not because they’re good - they’re irreplaceable because of the code they write. It’s so bad that only they can understand the code. You have no choice but to keep them around. Otherwise, no one else can take over and fix the mess. Bad developers can cost you and your business as much as the best developers. The only difference is that the best developers will leave your code in much better shape, allowing others to take over eventually. What Makes a Dysfunctional Software Development Team? Renowned author Patrick Lencioni, has a general description of what makes a team dysfunctional. According to Lencioni, a dysfunctional team will have the following characteristics: lack of trust, fear of conflict, no commitment, zero accountability, and members who ignore team objectives. Does this sound familiar? We’ve got bad news for you. In software development, this dysfunction isn’t just apparent based on how the team acts - it also shows in the results. You don’t even need to look at how the team is functioning to know if they’re dysfunctional. The source code will tell you all you need to know, and you don’t even have to be a software developer to find out if it’s a good or bad code! Here are signs of a dysfunctional software development team, based on the source code: 1. Ugly code You don’t need experience as a software developer to differentiate between bad code and good code. “Ugly” code isn’t subjective in software development. Ugly code, sometimes called spaghetti code, is exactly what these terms say — messy, dysfunctional, and unorganized. The best way to put it is in sports, like football and basketball, where fans use the term “poetry in motion” to describe what it’s like to watch the best and most skilled players perform. It’s similar in coding. Good code flows, complicated only when necessary, but still graceful and beautiful. On the other hand, lousy code oversimplifies things. It’s redundant and unnecessarily complicated. Overall, bad code looks like a mess. The best software developers, and in turn, good software development teams, write elegant code that’s easy to follow and pleasant to the eyes. If the code is confusing to look at, run. 2. Copy and pasting One of the reasons why bad developers write ugly code is they don’t optimize. They’ll just copy and paste the code from previous projects or, worse, the internet. Some will bother changing the variable or function names. But, they’ll often just take the code from somewhere else and hope it works. The resulting program might not show the jungle that’s happening in the source code. However, as the software scales, it will show. If you see variable names that are out of place and unrelated to the module, your software developers didn’t develop them on their own. When it comes to software development, clean code is essential. Why? Maintaining low quality code costs more and more time and money. It takes more efforts to understand bad code, make changes, and troubleshoot issues. The wort part is that new developers who have to work on that code must be really good at what they do to be able to understand and maintain it which usually means you have to pay higher price to hire best developers to clean up bad code. 3. Commented out code Most programming languages use double forward slashes for comments like “//”. If you’re new to programming, this is okay. Commenting out codes is a great way to try different approaches and discover what works — when you’re alone and starting out. But, it’s a problem if you’re working as part of a team in a professional setting, and it’s generally a sign of dysfunction and a lack of skill. In 99.9% of cases, commented-out code is practically useless. Eventually, this noise builds up, making it impossible to separate the real code from what actually works. This usually results from a trial-and-error approach by software developers who didn’t take the time to understand and solve the problem. Because of their lack of understanding, these incompetent software developers comment out older versions of their initial attempts in case they might need them in the future. Done collectively as a team, the source code just becomes a pile of failed code after another. The worst-case scenario is that the lead software developers can no longer understand which is which because of how bad the source code looks, so it gets harder for them to notice issues and address them. If that happens, good luck fixing issues, let alone optimizing the software. Dysfunctional Software Development Teams: A Security and Financial Risk Dysfunctional software development

Hiring software developers is costly. But do you know what’s more expensive? Hiring bad ones. There’s a marked difference in the quality of work between bad developers and good ones. The worst ones will cost you more money than you’d expect.
How so? One way of putting it is that it’s hard to replace bad developers, not because they’re good - they’re irreplaceable because of the code they write. It’s so bad that only they can understand the code. You have no choice but to keep them around. Otherwise, no one else can take over and fix the mess.
Bad developers can cost you and your business as much as the best developers. The only difference is that the best developers will leave your code in much better shape, allowing others to take over eventually.
What Makes a Dysfunctional Software Development Team?
Renowned author Patrick Lencioni, has a general description of what makes a team dysfunctional. According to Lencioni, a dysfunctional team will have the following characteristics: lack of trust, fear of conflict, no commitment, zero accountability, and members who ignore team objectives. Does this sound familiar? We’ve got bad news for you.
In software development, this dysfunction isn’t just apparent based on how the team acts - it also shows in the results.
You don’t even need to look at how the team is functioning to know if they’re dysfunctional. The source code will tell you all you need to know, and you don’t even have to be a software developer to find out if it’s a good or bad code! Here are signs of a dysfunctional software development team, based on the source code:
1. Ugly code
You don’t need experience as a software developer to differentiate between bad code and good code. “Ugly” code isn’t subjective in software development. Ugly code, sometimes called spaghetti code, is exactly what these terms say — messy, dysfunctional, and unorganized.
The best way to put it is in sports, like football and basketball, where fans use the term “poetry in motion” to describe what it’s like to watch the best and most skilled players perform. It’s similar in coding. Good code flows, complicated only when necessary, but still graceful and beautiful. On the other hand, lousy code oversimplifies things. It’s redundant and unnecessarily complicated. Overall, bad code looks like a mess.
The best software developers, and in turn, good software development teams, write elegant code that’s easy to follow and pleasant to the eyes. If the code is confusing to look at, run.
2. Copy and pasting
One of the reasons why bad developers write ugly code is they don’t optimize. They’ll just copy and paste the code from previous projects or, worse, the internet. Some will bother changing the variable or function names. But, they’ll often just take the code from somewhere else and hope it works.
The resulting program might not show the jungle that’s happening in the source code. However, as the software scales, it will show. If you see variable names that are out of place and unrelated to the module, your software developers didn’t develop them on their own.
When it comes to software development, clean code is essential. Why? Maintaining low quality code costs more and more time and money. It takes more efforts to understand bad code, make changes, and troubleshoot issues. The wort part is that new developers who have to work on that code must be really good at what they do to be able to understand and maintain it which usually means you have to pay higher price to hire best developers to clean up bad code.
3. Commented out code
Most programming languages use double forward slashes for comments like “//”. If you’re new to programming, this is okay. Commenting out codes is a great way to try different approaches and discover what works — when you’re alone and starting out. But, it’s a problem if you’re working as part of a team in a professional setting, and it’s generally a sign of dysfunction and a lack of skill.
In 99.9% of cases, commented-out code is practically useless. Eventually, this noise builds up, making it impossible to separate the real code from what actually works. This usually results from a trial-and-error approach by software developers who didn’t take the time to understand and solve the problem.
Because of their lack of understanding, these incompetent software developers comment out older versions of their initial attempts in case they might need them in the future. Done collectively as a team, the source code just becomes a pile of failed code after another.
The worst-case scenario is that the lead software developers can no longer understand which is which because of how bad the source code looks, so it gets harder for them to notice issues and address them. If that happens, good luck fixing issues, let alone optimizing the software.
Dysfunctional Software Development Teams: A Security and Financial Risk
Dysfunctional software development teams churn out poorly coded software with source code that’s difficult to understand and has little structure. Software architecture is a criminally underrated aspect separating well-coded from bad software.
Without an established software architecture, a software project will lack a solid foundation, have difficulty scaling, perform worse and worse over time, and ultimately have a growing number of security issues — a great way to find yourself on the wrong end of a lawsuit or bankruptcy, or in worse cases, both!
Security issues are really dangerous. Many don’t take them seriously enough until it’s too late, and it can affect even top companies who spend millions against cybersecurity threats.
In February 2024, the Change Healthcare cyberattack stopped most healthcare providers in the United States from operating after the company shut down its entire network to flush out hackers who had broken into the system. By the time the dust settled, Change Healthcare, a $10 billion company, was looking at multiple billions in losses incurred from this single incident, which included $2 billion or so in payouts to providers and facilities affected by the outage.
If you’re more technically knowledgeable, a good way to check for security issues is to check for broken access control issues.
Access control, as the name suggests, defines which users can access certain aspects of the application. A disciplined and well-managed software development team will stay on top of this, constantly updating access control rules to prevent exploits. A dysfunctional team couldn’t care any less. If you find several access control issues, the lead developer isn’t holding everyone on the team accountable.
Another way to find security issues is to look for hardcoded credentials. Third-party API integrations are commonplace in modern software. The best software development teams keep API keys and certificates secure. Hardcoding them shows laziness and a lackadaisical approach to storing third-party credentials.
But the absolute worst way to find out that you’ve hired a dysfunctional software development team is for customers to tell you about it. Are the end users struggling with functionality? Is your software unusable? Are your sales and marketing staff facing backlash? Frustrated and disappointed customers are the worst users — they won’t hesitate to leave bad reviews and comments. They’ll tell everyone about their experience, and you’ll lose money.
What to do to a Dysfunctional Software Development Team
If you start noticing signs that you’re working with a dysfunctional software development team, hire a third-party consultant. These professionals will provide an unbiased review of your source code, thoroughly evaluating its functionality and optimization. This third-party perspective can help you how to move forward.
At the end of the day, good software development teams hold themselves accountable. The bad ones don’t.
In software development, the source code is the pride and joy of a developer. It’s their baby. Most software developers get into this field to solve problems. They write code because they want to create and provide solutions. They’re not content with just copying other people’s solutions — they want to find out if they can take things a step further by finding a better solution.
Conclusion
Software development is more than just coding. Hiring a software development team for your software or app means working with professionals willing to work on different aspects of the project, including planning, troubleshooting, testing, quality assurance, and, more importantly, the user experience.
You want to work with a software development team that cares about every detail of the software, app, or website.
The source code is merely the driver for the end product. You need an app, software, or website that leaves end users happy and satisfied. A good software development team can deliver that and more.
Recognizing the signs of dysfunction within a software development team early can save you money and time and trouble dealing with potential legal issues and unhappy end users. Here at Developer Partners, we take pride in creating secure, scalable, and successful projects. We build applications that reduce overhead costs and help you with your bottom line.