Developer Responsability Principle
summary
Argues that developers can face legal consequences for shipped code and shows how readable, meaningful tests create credibility for systems. Uses concrete precedents: Joy Buolamwini’s face isn’t recognized by biased facial‑recognition libraries, and Volkswagen’s defeat‑device software manipulates emissions during testing and hides excess pollution for about seven years until students detect it. Recommends TDD, clear naming, layered unit/integration/acceptance tests and domain‑based test narratives; gives real bad test names from production and says tests must reflect expected behavior.
AI-written summary · about
chapters (21)
- 0:00Introduction and thanks
- 1:49Facial recognition bias example
- 3:39Software's pervasive impact
- 5:52Introducing user-focused principles
- 7:39Code organization and readability
- 9:25Code credibility and testing
- 15:19Meaningful tests and narratives
- 17:50Developer responsibility to future code
- 20:11Ethics and personal accountability
- 24:33Refusing unethical requests
- 27:02Data privacy and traceability
- 30:00Clarifying available vs accessible
- 31:50Changing systems vs leaving jobs
- 33:18Energy market and developer role
- 36:30Ethical implications of cloud services
- 39:46Raising awareness for users
- 41:34Collective action and team leverage
- 44:02Whistleblowing vs staying silent
- 48:12Legal systems and ethical frameworks
- 49:17EU whistleblower protections
- 50:21Taking action despite uncertainty
related talks
15mWhy TDD Is Crap
23mEthical Testing
46mThe responsible developer
54mSeeing Like a Programmer - Resiliency, Limits, And Moral Hazards In SE
46mProject Culture and Team Responsibility for Quality
13mTDD for Your Soul: Virtue and Web Development
43mTDD For Your Soul: Virtue Through Software Development
55mValues Driven Development