This article is based on reporting originally published on devops.com and draws on publicly available accounts of the events described.
When Bad Code Has Real-World Consequences
In March 2018, one of Uber’s autonomous test vehicles struck and killed a pedestrian in Tempe, Arizona. The incident became one of the most scrutinized software-related accidents in recent memory. Investigations revealed a troubling combination of factors: the safety driver behind the wheel was reportedly watching a streaming video on a personal device instead of monitoring the road, and the vehicle’s self-driving sensor system failed to correctly classify and react to the pedestrian in time to apply the brakes.
The National Transportation Safety Board (NTSB) investigated the crash extensively. While the full chain of causation involved human distraction, vehicle design decisions, and operational policies, software behavior was a central element of the NTSB’s findings. For the DevOps and software engineering community, the incident served as a stark reminder: the code teams write can have consequences far beyond a degraded user experience or a missed sprint deadline.
Ethical Pressure Inside the Organization
The Tempe accident did not arise in a vacuum. Prior to it, Uber had already attracted significant negative attention for a range of alleged internal practices. Former software engineer Susan Fowler published a widely read account in early 2017 describing a culture of sexual harassment and management misconduct. Separately, Uber faced accusations that its engineering teams had built tools designed to exploit driver earnings, evade regulatory oversight, and deny service to passengers in ways that skirted legal boundaries.
These allegations, if accurate, represent a scenario in which software developers were asked—explicitly or implicitly—to write code in service of goals that were ethically or legally questionable. This raises an important question for every engineering organization: what happens when the people with the ability to build something are also the first line of defense against building something harmful?
What Developers Say They Would Do
Stack Overflow’s annual developer survey, which at the time of the original reporting included responses from more than 100,000 developers worldwide, offered some data on how engineers think about ethical responsibility. When asked what they would do if asked to write code for an unethical purpose:
- 58.5% said they would refuse to write it.
- 36.6% said their response would depend on the specific situation.
- 4.8% said they would write it.
On the surface, these numbers are encouraging. A strong majority of developers report a willingness to refuse unethical work. However, Stack Overflow noted a significant grey area in the findings: developers were largely uncertain about how they would report an ethical concern, and they held widely differing views about who bears ultimate responsibility when unethical code is shipped. That ambiguity is the real problem.
The Grey Area: Responsibility and Reporting
Knowing that you should refuse to write harmful code is not the same as knowing what to do next. In practice, engineers face a layered set of pressures: sprint deadlines, management directives, fear of retaliation, uncertainty about whether their concern is legitimate, and a general sense that someone higher up the chain must have already considered the implications.
This diffusion of responsibility is well-documented in organizational psychology. In software teams, it can manifest as a situation where no individual developer believes they are personally responsible for the ethical dimensions of a system, even as the system as a whole causes harm.
What DevOps Teams Can Do
Torsten Volk, an analyst at Enterprise Management Associates (EMA), argued that DevOps is uniquely positioned—and uniquely obligated—to build ethical guardrails into development culture. He identified several concrete mechanisms:
1. Full Audit Trails
Maintaining clear, immutable records of who wrote what code and when creates accountability at the individual contributor level. Volk noted that knowing an audit trail exists makes developers more likely to raise concerns with team leads before problematic code ships. Source code management systems like Git already provide the technical foundation for this; the cultural commitment to treating those records as an ethical tool is what organizations often lack.
2. Documented Ethics Discussions
When a developer flags an ethical concern, the outcome of that conversation should be documented—ideally in the same source code management or issue-tracking system the team already uses. This transforms a potentially invisible conversation into a traceable decision, and it protects the developer who raised the concern.
3. Psychological Safety for Raising Concerns
No audit trail matters if developers fear retaliation for speaking up. Organizations must actively cultivate an environment where raising an ethical red flag is treated as a professional responsibility rather than insubordination. This means leadership modeling the behavior, not just writing it into a policy document.
4. Connecting Ethics to Business Risk
Volk also argued that organizations should frame ethical coding practices in terms that resonate at the executive level: risk management and bottom-line impact. Unethical code is not just a moral failure; it is a liability. Regulatory penalties, reputational damage, and the cost of incident response all have quantifiable business consequences. Drawing a direct line between ethical engineering practices and reduced organizational risk is one of the most effective ways to secure sustained leadership buy-in.
Volk drew a parallel to GDPR compliance, suggesting that organizations could similarly recognize and publicize outstanding examples of ethical conduct in development—signaling to customers and partners that responsible engineering is a competitive differentiator, not just a cost center.
Building an Ethical Engineering Culture
The Uber case should not be read as an indictment of autonomous vehicle technology or of DevOps culture writ large. The majority of software developers, as the Stack Overflow data suggests, want to do the right thing. The challenge is structural: organizations must make it easy—and safe—for developers to act on their ethical instincts.
Practical steps for engineering leaders include:
- Adding an ethics review checkpoint to your Definition of Done or pull request template.
- Including ethical risk assessment in architecture decision records (ADRs).
- Running scenario-based ethics training as part of onboarding and continuing education.
- Establishing a clear, non-punitive escalation path for engineers who have concerns about a feature or system they are being asked to build.
- Ensuring retrospectives can surface ethical concerns, not just process inefficiencies.
Software is not neutral. The decisions made during a sprint—what a sensor system is optimized for, how an algorithm weights certain outcomes, which edge cases are treated as acceptable losses—can ripple outward in ways that affect real people. DevOps culture, with its emphasis on shared responsibility, continuous feedback, and transparency, is well suited to make ethical accountability a first-class engineering concern rather than an afterthought.