Friendship Driven Development
February 2023
As software engineers and bearers of the logical mind, we like rules, objective principles that can get us from A to Z safely and quickly.
Whether it’s the SOLID principles, Onion Architecture or DRY (SOD? DOS? yeah I need to work on good acronym of acronyms for this), these tools give was a way to look at problems such that we can apply known solutions to them.
Which is great, but I’ll propose that none of that matters that much. Everything we do in our professional lives is ultimately, for people. And in many cases for software engineers, our current and will be friends.
Well, sure if you’re running a startup, grinding away the day just trying stay afloat, do what you must! No one has the right to criticize your situation.
But, if you’re not, I’ll ask that you consider, instead, writing software for people.
I then introduce you to Friendship Driven Development
FDD, as it is now known (since just minutes ago), has only 4 complementary approaches to its practices:
- We write code (design, architecture) for people. Machines might cute it but it’s people who will have to read it, internalize it act on it
- We step outside ourselves to consider other languages, cultures, the diverse mind. What seems trivial and may make sense to us quite possibly doesn’t to everyone else.
- What’s in our heads at the moment we’re writing code is not the same everyone else will have.
- We are not dogmatic about FDD and that is because, in the end, the value we get from it comes from helping people and not from practicing FDD itself.
We can take good care of the code while taking good care of people too.
Thanks for listening.
P.S. I’ve been told FDD stands Feature Driven Development but I’ll run with it and let the reader decide how to use it.