The Cost of Bad Development: Why Hiring Poor Code Can Be More Expensive Than You Think
When managing software projects, one of the critical decisions is whether to continue investing in a developer’s work or to replace them. Many underestimate the long-term costs associated with bad code, often believing that fixing issues later will just be part of the process. However, experience shows that allowing subpar code to persist can end up costing more than you might expect — both financially and in terms of productivity.
Here are two real-world examples from recent projects that illustrate the hidden costs of poor development.
Case Study 1: Inefficient Data Retrieval in a Symfony API
In a small-scale Symfony API project—my first experience with the framework—a developer who has since left the company crafted the core endpoints. The endpoint’s purpose was straightforward: return the latest weather data for a specific weather station. For example, calling /weatherstation/1 would fetch data for station 1, while omitting the ID or passing zero would retrieve all stations.
The issues began with how the developer implemented data retrieval. Instead of fetching only the most recent entry per station, the code retrieved all entries for each station. Given that the API had been live since mid-2024, each station accumulated roughly 30,000 entries. When multiple requests were made, the server responded slowly—resulting in load times of up to 6 seconds on the weather page.
What caused this delay? Sequential API calls for each station, each response taking hundreds of milliseconds, combined with the enormous volume of data transferred—up to 80MB per request—due to fetching and sending all historical weather data instead of just the latest entry. This inefficient design forced the current team to dedicate significant time and resources just to fix what should have been a simple task.
Case Study 2: Database Mishandling in an Order Management Application
Another example involves an order management system I worked on as a freelance developer. Over two years, the application regularly experienced performance issues and data inconsistencies. One source of recurring problems was retrieving items from the database without maintaining proper order.
In one instance, the application generated delivery notes that listed products and quantities. The core issue was that the code fetched two separate lists from the database—one for products, another for quantities—without ensuring they matched correctly. The mismatch led to incorrect delivery notes, causing logistical errors. Additionally, instead of storing ordered data efficiently in the database, some info was retained
