\u003C/figure>\n\u003C!-- /wp:image -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cem>Source: \u003C/em>\u003Ca href=\"https://martinfowler.com/articles/is-quality-worth-cost.html\">\u003Cem>“Is High Quality Software Worth the Cost?”\u003C/em>\u003C/a>\u003Cem> by Martin Fowler\u003C/em>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>For any project that lasts more than a few weeks, development speed is partially dependent on code quality. This is a significant factor in total cost of ownership—in other words, the company’s bottom line is directly at risk. \u003Ca href=\"https://sites.pitt.edu/~ckemerer/CK%20research%20papers/SwComplexityAndMaintenanceCost_BankerDatar93.pdf\">One study\u003C/a> found that complexity accounts for 25% of the cost of software maintenance and over 17% of total software lifecycle costs. \u003Ca href=\"https://www.cnbc.com/2018/09/06/companies-worry-more-about-access-to-software-developers-than-capital.html\">And a 2018 poll by Stripe\u003C/a> found the worldwide cost of dealing with “bad code” to be as high as $85 billion per year. These numbers only address costs in terms of development time and payroll; the costs of shipping defective software or being beaten to market by a competitor are also worth considering. Since the effects of bad code persist until it is removed, the only sensible approach is to deal with it early and often.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Second, code quality is a factor in \u003Ca href=\"https://www.computer.org/csdl/magazine/so/2019/05/08802319/1cw1Hxe8rMQ\">job satisfaction\u003C/a> among programmers. Companies that want to attract world-class talent, increase employee engagement, and limit turnover can’t afford to ignore this relationship. Turnover in particular is a \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/1355238.1355245\">studied factor\u003C/a> in the success or failure of software projects. This is likely because programmers \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/2786805.2786870\">make more mistakes\u003C/a> on projects they are less familiar with.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Third, code quality drives product quality. High-quality code is \u003Ca href=\"https://link.springer.com/article/10.1007/s10664-011-9171-y\">less likely to have bugs\u003C/a>, which are a major driver of user complaints. Code quality has also been correlated to \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/3197231.3198447\">commercial success\u003C/a> and \u003Ca href=\"https://ieeexplore.ieee.org/document/8819456\">reduced security vulnerabilities\u003C/a>. Code quality certainly isn’t the only factor in a product’s performance on the market, and it likely isn’t the most important factor either. But even the most competent organizations will struggle to market a product that’s bug-ridden or vulnerable to hacks.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-how-organizations-can-increase-code-quality\">How organizations can increase code quality\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Code quality requires investment. It can’t be increased without the commitment of resources—money, development time, and deadline negotiation being the most prominent of these. It also can’t be increased by the use of threats, punishment, or overtime; code can’t be improved under the conditions that lead to bad code in the first place! The good news is that refactoring—the practice of actively increasing the quality of a codebase—does not require all other development activities to cease. It can become a regular and minimally-disruptive part of the development process, something the team attends to while continuing to build and improve features.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Following are some organizational habits and competencies that promote higher-quality code.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-sustainable-pace\">Sustainable pace\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Programming is difficult under the best of circumstances. As mentioned earlier, a programmer’s ability to code is profoundly dependent on their mental state. Happiness, \u003Ca href=\"https://repository.lib.ncsu.edu/bitstream/handle/1840.16/10358/etd.pdf?sequence=1\">sufficient rest\u003C/a>, and low stress levels are all important ingredients. \u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The first way to ensure programmers have enough mental resources to do their best work is to \u003Ca href=\"https://www.researchgate.net/profile/James-Cusick/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality/links/0f31752dd77ad07cc0000000/Impact-of-Overtime-and-Stress-on-Software-Quality.pdf\">avoid overtime\u003C/a>. The quality of a programmer’s code drops by the end of a standard eight-hour workday, let alone in the hours beyond. Many programmers have had the experience of coding while excessively tired, stressed, or sick, then discovering the next day that all their work has to be undone or rewritten. This is “net negative work,” code so low-quality that it actually increases the amount of work remaining on the project. Nothing can compensate for a lack of rest over the long term—neither caffeine, nor micro-napping, nor ping-pong tables, nor free beer can replicate the benefits of a restful evening and a good night’s sleep.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Companies that foster burnout by insisting on constant overtime are not just abusive, they’re self-defeating. Any initial gains in productivity will be rapidly drowned out by poor quality. On the other hand, companies that pace their development teams on a short, sustainable and flexible workday, allowing plenty of time off and sick leave, can expect consistent and high-quality output over the long term.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A common cause of overtime in otherwise competent organizations is deadline pressure. Deadlines are often based on financial motivations or scheduling concerns rather than the realities of software development. Programmers can’t speed up a project by thinking harder or typing faster. When a deadline approaches they generally take the only shortcut available to them, which is reduction of quality. This can be avoided by careful planning and strategizing around deadlines.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The first part of this is estimation. Software estimation is a \u003Ca href=\"https://stevemcconnell.com/17-theses-software-estimation/\">complex skill that requires specific training\u003C/a>. Most programmers and managers have not had this training. In the absence of estimation skills, teams are at risk of falling back on oversimplified formulas like “guess how long it will take, then double that guess, then double it again.” The best case scenario here is that the project is done early and project managers are left improvising ways to fill leftover development time. But the worst case scenario is that the project is delivered late or barely functional. So if an organization lacks the time or the will to build software estimation skills, it’s far better to negotiate for extremely generous deadlines than to end up disappointing customers.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The second part of deadline management is prioritization. Prioritization is not just about which things are built first; it’s about which things are built at all. Every development roadmap is liable to include features that are overvalued (difficult to build and not especially valuable to users) or undervalued (easy to build and very valuable to users). An effective manager will focus their team’s efforts on the latter end of the spectrum, especially as deadlines loom close.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If deadlines are managed well, they can be an effective motivator toward the team’s software delivery goals while also leaving enough time for things to be built right. Software quality, as much as anything else, requires dedicated time.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-refactoring-as-part-of-the-development-cycle\">Refactoring as part of the development cycle\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Technical debt, like a weed, springs up regardless of what we may do to prevent it. While some development practices can reduce it substantially, there is no way to eliminate it without the benefit of hindsight. Keeping it to a minimum means regularly taking time to find, discuss, and fix it.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Many organizations use \u003Ca href=\"https://theuxcto.com/digital-blitz/the-80-20-rule-to-deal-with-technical-debt-refactoring/\">the “20% rule”\u003C/a> as a guide: 80% of development time is spent on feature development or bugfixes and 20% is spent on refactoring. This principle works best when applied loosely, since teams can’t predict exactly how long a given task will take. And there may be occasional cycles when technical debt has become such a hindrance that it requires a team’s full attention, or cycles when there are pressing feature releases to attend to and technical debt has to take a back seat. The organization should take care not to fall into the trap of doing either of these for longer than necessary.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>For the best results, technical debt tasks should be first-class citizens of the planning process. That is, they should exist alongside features, bugs, and testing tasks in the team’s planning software (or on their whiteboard, as the case may be). The 20% rule can be adopted as simply as “one out of every five tasks is set aside for refactoring.” This doesn’t necessarily require technical debt tasks to be planned and scoped to the same level of detail as feature tasks. Rather, the goal is to ensure that the team’s refactoring work is visible and the time they spend on it is protected.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-technical-leadership-and-review\">Technical leadership and review\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Code quality is second nature to many programmers. They recognize low-quality code, understand its effects, and know how to fix it. To other programmers, the concept is entirely foreign. If a project is staffed entirely by the latter, it doesn’t take long for it to end up mired in slow development and technical issues.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>What’s the difference between these two groups of programmers? The answer is simple: study and intentional practice. Unfortunately, neither \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/3174781.3174785\">colleges\u003C/a> nor bootcamps nor \u003Ca href=\"https://link.springer.com/article/10.1007/s10664-016-9471-3\">years of industry experience\u003C/a> can be relied on to instill the relevant skills—nothing on a programmer’s resume will necessarily set them apart. But this shouldn’t keep hiring managers up at night. Code quality and refactoring skills can be learned at any stage of a programmer’s career and are far less complex than many of the other concepts they deal with. The quality of a programmer’s work can increase dramatically over the course of a few months if they have access to the right resources and are willing to improve.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>What’s more, a software organization can thrive even when their programmers are unevenly skilled. If practiced programmers are chosen to lead the architecture, design, and planning of software projects, their understanding of code quality will be part of the DNA of the development cycle. This kind of technical leadership is essential to high-quality software.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Skill gaps can also be bridged with various forms of review:\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>\u003Cstrong>Design reviews\u003C/strong> happen after a task is specified but before any code is written. The programmer assigned to the task writes a document outlining their approach: the files, classes, and methods they plan to update; the patterns and techniques they will use; and any uncertainties they may have about design or business logic. Then another programmer gives feedback on that document, which may include correcting misconceptions and suggesting helpful patterns or methods that already exist in the codebase. The time taken by this process is sometimes substantial, but it’s a worthwhile investment. Catching a defect this early in the development process is \u003Ca href=\"https://www.researchgate.net/figure/IBM-System-Science-Institute-Relative-Cost-of-Fixing-Defects_fig1_255965523\">extremely cheap\u003C/a> relative to the cost of discovering and fixing it later.\u003C/li>\u003Cli>\u003Cstrong>Pair programming\u003C/strong> is the practice of assigning two programmers to complete a task together in real time. One programmer controls the keyboard and mouse while the other programmer gives directions. This allows for instantaneous review, feedback, and knowledge transfer during development. Studies have found \u003Ca href=\"https://link.springer.com/chapter/10.1007/3-540-44870-5_27\">mixed\u003C/a> \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/1062455.1062545\">results\u003C/a> as to the raw productivity of two programmers working together versus solo (although it seems to offer a \u003Ca href=\"https://www.sciencedirect.com/science/article/abs/pii/S1071581906000644\">more consistent productivity boost\u003C/a> to inexperienced programmers). However, when code quality is taken into consideration, pair programming is almost \u003Ca href=\"https://dl.acm.org/doi/abs/10.1145/1414004.1414026\">universally\u003C/a> \u003Ca href=\"https://ieeexplore.ieee.org/abstract/document/854064\">recognized\u003C/a> as \u003Ca href=\"http://www.dsc.ufcg.edu.br/~jacques/cursos/map/recursos/XPSardinia.pdf\">advantageous\u003C/a>.\u003C/li>\u003Cli>\u003Ca href=\"https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/\">\u003Cstrong>Code reviews\u003C/strong>\u003C/a> happen after code is written but before it’s shipped as part of the product. A programmer makes their code changes available to the rest of the team. Then another programmer reads them and gives feedback, often suggesting changes that should be made before the code is shipped. Many code quality issues can only be recognized by a human. This is the last opportunity to catch those before they become part of the product.\u003C/li>\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If team members are frequently required to check each other’s work and there are no major hostilities or communication failures between them, the quality of their collective work will rise toward the level of the most practiced programmer’s.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-code-quality-is-a-competitive-advantage\">Code quality is a competitive advantage\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Research on code quality is not scarce (if the 25+ studies linked above aren’t enough, there are \u003Ca href=\"https://scholar.google.com/scholar?hl=en&as_sdt=0%2C45&q=code+quality&btnG=\">plenty more\u003C/a>). Time and time again it’s been demonstrated to be a factor in project success or failure, time-to-market, and product longevity. Organizations that prioritize healthy codebases are prioritizing their customers, their programmers, and their own financial viability.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Code quality is also one of the great gifts we programmers can give to ourselves and our colleagues. If we spend a few extra moments naming a variable, rewriting deeply-nested logic, or making a function more predictable, those moments will be paid back in full many times over as we interact with that code over the life of the project. Thinking about how our code affects computers is the bare minimum; thinking about how our code affects humans is a powerful form of empathy in practice, one that no organization can afford to ignore.\u003C/p>\n\u003C!-- /wp:paragraph -->","html","2021-10-18T14:00:00.000Z",{"current":962},"code-quality-a-concern-for-businesses-bottom-lines-and-empathetic-programmers",[964,972,977,982],{"_createdAt":965,"_id":966,"_rev":967,"_type":968,"_updatedAt":965,"slug":969,"title":971},"2023-05-23T16:43:21Z","wp-tagcat-code-for-a-living","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":970},"code-for-a-living","Code for a Living",{"_createdAt":965,"_id":973,"_rev":967,"_type":968,"_updatedAt":965,"slug":974,"title":976},"wp-tagcat-code-quality",{"current":975},"code-quality","code quality",{"_createdAt":965,"_id":978,"_rev":967,"_type":968,"_updatedAt":965,"slug":979,"title":981},"wp-tagcat-software-engineering",{"current":980},"software-engineering","software engineering",{"_createdAt":965,"_id":983,"_rev":967,"_type":968,"_updatedAt":965,"slug":984,"title":986},"wp-tagcat-tech-debt",{"current":985},"tech-debt","tech debt","Code quality: a concern for businesses, bottom lines, and empathetic programmers",[989,995,1001,1007],{"_id":990,"publishedAt":991,"slug":992,"sponsored":951,"title":994},"e10457b6-a9f6-4aa9-90f2-d9e04eb77b7c","2025-08-27T04:40:00.000Z",{"_type":10,"current":993},"from-punch-cards-to-prompts-a-history-of-how-software-got-better","From punch cards to prompts: a history of how software got better",{"_id":996,"publishedAt":997,"slug":998,"sponsored":12,"title":1000},"65472515-0b62-40d1-8b79-a62bdd2f508a","2025-08-25T16:00:00.000Z",{"_type":10,"current":999},"making-continuous-learning-work-at-work","Making continuous learning work at work",{"_id":1002,"publishedAt":1003,"slug":1004,"sponsored":12,"title":1006},"1b0bdf8c-5558-4631-80ca-40cb8e54b571","2025-08-21T14:00:25.054Z",{"_type":10,"current":1005},"research-roadmap-update-august-2025","Research roadmap update, August 2025",{"_id":1008,"publishedAt":1009,"slug":1010,"sponsored":12,"title":1012},"5ff6f77f-c459-4080-b0fa-4091583af1ac","2025-08-20T14:00:00.000Z",{"_type":10,"current":1011},"documents-the-architect-s-programming-language","Documents: The architect’s programming language",{"count":1014,"lastTimestamp":1015},25,"2023-05-25T09:47:41Z",["Reactive",1017],{"$sarticleModal":1018},false,["Set"],["ShallowReactive",1021],{"sanity-kESmn2LUY7hxMAUID7YD4inmqsr22D7mYBcJJCjeiKE":-1,"sanity-comment-wp-post-18941-1756370338005":-1},"/2021/10/18/code-quality-a-concern-for-businesses-bottom-lines-and-empathetic-programmers"]