Developers Behaving Badly

There is a trope of the “Lazy Developer” who is equal parts haphazard, irresponsible, at times intoxicated by hubris, and perhaps even deficient of pride in their craft to do things by the book. The Lazy Developer pushes code to production (prod) without testing and doesn’t follow OpSec best practices because process and protocols only slow them down. 

It’s important to note that 2023 started as a year of mass layoffs in tech, leaving those left with the burden of extra work; 77% of developers say they’ve taken on more testing responsibilities in the last year due to organizational changes. 

So how accurate is the Lazy Developer trope, and what are some of the industry practices that allow it to persist? Is the root of the trope actually lazy developers, or are there bigger forces at play? Furthermore, what actions can companies take to stem the cause and effect of the Lazy Developer trope? 

In this study, we surveyed 500 US-based people employed full time as developers, and in their current role for at least a year. The results revealed some eye-opening statistics that illustrate the risks and liabilities raised by developers that don’t comply with quality and safety processes. We also saw patterns that might point to a plausible explanation—and a potential solution—for the issues raised by so-called Lazy Developers. 

Software developers don’t always shy away from the Lazy Developer trope; in fact, many revel in it, making and sharing memes about recklessly pushing to prod. But how bad is it, really? Well, “pretty bad,” if you had to qualify it.

We asked our sample of 500 developers about some common transgressions that the Lazy Developer is often accused of, and provided the space to anonymously confess their trespasses. All answers are limited to their experience at their current employer, not simply “Have you ever…” Let’s dive in. 

In their current role, over two-thirds of respondents (67%) admitted to pushing to prod without testing, while over a quarter (28%) of respondents regularly do so. Pushing to prod without testing jeopardizes software quality, user experience, and overall system stability. Regularly bypassing essential testing phases exposes businesses to potential security vulnerabilities and risks that could damage brand reputation and trust. In an era where seamless digital experiences are paramount, such oversights can lead to significant financial and reputational losses.

If we split the statistics by age, we see a trend emerge: 92% of respondents aged 58+ report that they have rarely or never pushed to prod without testing in their current job. While the number of respondents in this demographic is small (20 cases), it is in stark contrast to the 55% of the aggregate sample. This large delta suggests that even if the sample size is statistically insignificant, it is directionally indicative of a trend. The disparity might suggest that with age comes wisdom and prudence. A less charitable supposition is that the more seasoned developers are more obedient; a more practical interpretation is that developers in this demographic are typically in leadership roles where opportunities to push to prod are limited, and their coding contributions are generally neither time-sensitive nor mission-critical.

Developers don’t just push their own untested code to prod without testing; 61% of developers admit to using untested code generated by ChatGPT, and more than a quarter of them (26%) do so regularly.

We asked how many developers merge their own pull requests without a review, and the results were strikingly similar to those who push to prod without testing; no doubt there is a lot of overlap between these two questions: 68% of developers have merged their own pull requests without a review, and 28% report doing so often or very often.

However, when we split the results by age, the similarity to those who push to prod without testing diverges. We still see the general correlation between age and greater conservatism, but not at the low end. 19% of the youngest demographic (ages 18-24) trends toward the oldest demographic (age 58+) to ostensibly form a natural distribution. This might be explained by the fact that younger developers are more cautious, or perhaps more closely managed and unable to take such liberties. Developers aged 25-41 are the most likely to regularly merge without review (32%), and after that—whether it’s from the natural wisdom that comes with age or from learning the hard way too many times—the number dips to 23% of the 42-57 age group.

Everyone knows the importance of cybersecurity; the average cost of a data breach in the US in 2023 weighs in at $9.49 million, according to IBM. And yet… 

Shockingly, 70% of our survey respondents admitted to using a coworker’s credentials in order to circumvent company restrictions for access to data and/or internal systems at their current job, and 41% of respondents do so regularly. As staggering as that figure is, it gets worse. 

75% of developers—3 out of every 4—admit to circumventing security protocols in their current role (such as disabling MFA, or an unstable VPN) to complete a task, while 39% of developers report doing so routinely. 

And developers don’t just take shortcuts with their own data: 60% admitted to sharing unredacted data with an unauthorized individual when troubleshooting or fixing a process, and 70% admitted to bypassing data encryption when transferring sensitive data to make the process faster or simpler. As discrete transgressions, these may seem low risk, but in the aggregate they create a tremendous amount of surface area for bad things to transpire.

Lazy isn’t always bad; a (probably apocryphal) Bill Gates quote actually extols the value of lazy developers. In many ways, it’s a developer’s job to find the path of least resistance (or less charitably, to take shortcuts). Developers are often faced with challenges for which there are no existing solutions, no blueprints for success; instead, they need to problem-solve a creative solution. What are their constraints, what are their available resources, what is their ultimate deliverable? A developer is tasked to make a triangulation of these factors and come up with the simplest solution. So if a developer takes liberties with process or security, perhaps their main constraints are low bandwidth and/or unreasonable demands, and loosely (or not) adhering to best practices is their solution to get the job done in the required time. The finer nuances of acceptable risk and reward can be debated, but largely, bad developer behavior is a systemic issue, not a broad conspiracy of individual malicious actors. 

Before blaming these so-called “lazy developers,” organizations should re-evaluate their testing processes and security protocols. If developers, ever looking for a faster/easier solution, embrace cutting-edge tools like ChatGPT, shouldn’t your testing/security practices and tools also be cutting-edge? Tools like Tailscale solve developer access issues so sharing credentials or circumventing systems are not a temptation. Automated and continuous testing practices mean testing in prod is happening because it’s a best practice, not because it was neglected up to that point.

There’s an old saying in software development, “Fast, good, cheap; pick two.” Known as the Iron Triangle or sometimes Triple Constraint, this model is the source of the tension that causes good developers to stray. Leadership needs to solve the Iron Triangle, and their primary tools for mitigating it are clarity of goals and expectations, and the trust in their lieutenants (the managers), to make it happen.  

Leaders also need to remember what they learned in business school (yet apparently forget every time earnings season or a tense board meeting nears): don’t cut short term costs at the expense of your company’s long-term health. Invest in tools that improve developer experience, or those that make security more user-friendly without compromising on safety. And don’t shift left by simply gutting your QA team and expecting developers to pick up the slack.

Buggy software may not have immediate repercussions beyond some extra support tickets, but the opportunity cost of bad code is significant. In a 2022 Sauce Labs survey, 64% of users who encounter an error say they’ll only reload a page or restart an app 2-3 times before giving up, and 63% of users say a bad digital experience can make them feel like their data is not secure with that brand. 

In addition to leaning on managers and employing long-term thinking, company leaders should promote a culture where quality, safety, and transparent communication are not afterthoughts, but business as usual. These values should not only be evident in the SDLC, but embedded in the company culture. Company leaders are responsible for setting the strategy, and their lieutenants (managers) outline the product/IT requirements needed to achieve company goals. If developers are constantly taking shortcuts and security risks, that’s a sign that leaders need to set clearer expectations (that, or set goals more firmly planted in reality), and managers need to refine processes, tools, and provide the appropriate resources to achieve desired outcomes without sacrificing quality or safety. 

As is so often the case, bad developer behavior is a result of institutional structures more than it is a symptom of personal failings. While this behavior may never disappear from the workplace, every shortcut not taken is one less opportunity for catastrophe. 

This random double-opt-in survey of 500 Developers (frontend, backend, or full stack developers) was commissioned by Sauce Labs between July 22 and August 1, 2023. It was conducted by market research company OnePoll, whose team members are members of the Market Research Society and have corporate membership to the American Association for Public Opinion Research (AAPOR) and the European Society for Opinion and Marketing Research (ESOMAR).