Respect Driven Development is not an attempt to add to the Agile alphabet soup of X Driven Development like TDD, BDD, DDD or FDD. I consider it to be more of an attitude than a process. The idea started to germinate the more I worked on Big Data projects, which have not always turned out to be beneficial for all. I have done significant work with banks on compliance issues with regulations like Basel and Dodd-Frank so I’m familiar with having to go back and put systems in place in response to a real crisis. It really wasn’t until GDPR that I started to think that we really need a way to internalize how we approach data as developers in large distributed systems.
GDPR was a tipping point for me because of my views on the benefit, if not necessity, of immutable data sets. Immutable datasets have been a mantra for me since I first started dealing with distributed systems. Avoiding mutability made consensus workable. I also do a significant amount of work in blockchain now. Now GDPR comes along and says that people have a right to be forgotten. And I completely agree. Why am I designing and developing systems that I don’t really want to use? Keep in mind this isn’t a technical blocker. I can create immutable datasets where I store personally identifiable information encrypted and read the data through a decryption layer that’s tied to my consent records. Not only have I never implemented this type of system, I’ve never suggested it as an architectural consideration that could have positive downstream benefits for our clients. This is my concern: what other patterns that I take for granted need to be revisited?
I spent a weekend in Scrum training with Vernon Stinebaker and he made a comment that really directed my thinking on this subject. He was going over the Scrum Values a commented that Respect is actually the core value from which the rest derive.
- Respect the Client: privacy and integrity come before features
- Respect the Business: consistency and transparency are more valuable than velocity
- Respect the Team: pair programming is the fastest path to mutual respect
- Respect the Next Team: tackle small modules thoroughly and test deeply
- Respect the Code: only build muscle memory on quality code; prototypes often make it to production
- Respect the System: continuous integration/continuous delivery makes happy sysadmins
Building massively scaled distributed systems have brought about some ethical issues that we haven’t really addressed collectively as developers. We haven’t been acting in bad faith, of course, but it never hurts to step back and look at the big picture. Especially when it keeps getting bigger.
