In this episode of Appian Rocks, Stefan, Sandro, and Marcel dive into a conversation that starts with the seemingly dull topic of software reviews but quickly evolves into a deep and thought-provoking discussion about ethics in digital process automation. Initially, they touch on the typical components of a code review—adherence to best practices, syntax, node counts in processes, and test cases. However, they challenge the narrow scope of this approach, questioning whether technical correctness alone is sufficient, especially when the software influences real-world decisions in complex environments. The conversation shifts to the broader context in which applications operate, especially in public sector projects. The team notes that stakeholders such as the funding agency, the users, and the beneficiaries are often different entities, each with distinct priorities. This creates a tension where developers can find themselves caught in the middle. While developers are typically not policy makers, the code they write can enforce rules and decisions that significantly affect people's lives. This leads to a central theme of the episode: software is not neutral. It embodies decisions, and those decisions can have ethical consequences. They explore how public sector automation transforms discretionary, human-driven processes into rigid, rule-based systems. This transition, while increasing efficiency, risks stripping away the nuance and empathy that experienced civil servants once applied. For example, decisions about child support or eligibility for government aid, which were previously made by humans considering context and individual circumstances, are now reduced to logic gates and business rules. The trio argues that this change demands new layers of oversight—beyond testing whether a process works, teams must ask whether it works *fairly* and *justly*. A particularly striking point raised is the lack of ethical audits in most software development projects. Stefan admits he’s never performed one, and the group collectively questions why such audits aren't standard practice. Is it because they were never needed? Or is it because ethical responsibility was previously embedded in human roles and not in the tools themselves? They agree that developers, especially solution designers and business analysts, have a duty to consider the broader impacts of their implementations. The discussion also touches on traceability and transparency. Marcel introduces the concept of traceability as a critical requirement, particularly in government software. Every feature in an application should be traceable back to a signed-off requirement to ensure accountability. This is essential not only for auditing but also for safeguarding citizens’ rights when decisions are automated. Transparency, too, is highlighted as a core value—systems should provide users with understandable explanations for decisions, such as why a child support claim was denied. As the episode closes, the hosts underline the need for ethical codes within development teams. Guidelines alone aren’t enough; teams must establish practical escalation paths and support for developers who encounter ethical red flags. Developers should feel empowered to say no to unethical requests and escalate questionable requirements. Ethical responsibility, they stress, belongs to everyone involved—not just legal or compliance departments. Ultimately, this episode calls for a shift in mindset. In an era where software often replaces human discretion, ethics must become a first-class concern in digital process design. Developers, architects, and analysts need to see themselves not just as implementers of logic, but as stewards of values that impact real lives.
