The subtleties of developer commitment

In a recent post, I concluded that I have a strong tendency towards tactical architecture. From that perspective, I try to avoid big-design-upfront. I have a built-in allergy for rebuilding stuff that is already out there. I would never consider building my own message bus or event sourcing framework for instance. I also react pretty strongly when people are suggesting things like that and believe that this is a common source for project failures. I know that I myself can be way too optimistic about any development work I'm starting, regardless of my pessimistic eye for roadblocks and risks. So if an experienced developer claims some big design thing is going to be pretty easy or obvious, they'll have a very hard time convincing me.

But there are two other factors to include in such a tradeoff. First of all, I do know that occasionally some level of strategic architecture is needed. You can't just build a large scale distributed system without doing at least a decent amount of upfront design. But even then I'd like to keep an eye on the reversibility of such a design decision. In other words, if we can postpone a design decision without having to undo or redo a lot of work later on, then I would postpone the decision. If we can't, than yes, a much more elaborate design has to be done first.

The other factor is about the commitment your fellow developers will towards a design. Here, with commitment, I mean how responsible they feel for a certain component or design choice. This is a question I've been pondering on for years and has been, and still is, one of the most difficult tasks to cope with. It's ironic how I decided to go pursuit a technical career where my biggest challenges are people related. Over the years, I've learned that ultimately a person feels most responsible for the choices they made themselves. A theory that Christopher Avery's stages of responsibility illustrates well. On a larger scale, where individual choices are becoming less relevant, you can use techniques as covered by the Culture Engine to get people to commit to certain organizational choices.

All in all, you can see how this tradeoff has some pretty important subtleties. So what happens when you get eye-to-eye with another developer that has contrasting ideas on how to approach software architecture? I have not finalized my conclusion yet. But right now I'm in a similar situation where I've given the people around me a lot more room to do what they think is best than I usually do. I was reluctant about some of their ideas, and I still have some reservations, but I do see a lot of commitment for the decisions they have made. By now, they’ve realized building some of the things they are building isn't as trivial as they thought. Each day we run into more little obstacles, but they keep doing what it takes to make it a success. Ultimately however, we'll have to see if that's enough and whether or not my suspicions were correct.

So what do you do to get the developers in your teams to feel responsible for the things they are working on? Let me know by commenting below or tweeting me at @ddoomen.