Over a million developers have joined DZone.

The Subtleties of Developer Commitment

DZone's Guide to

The Subtleties of Developer Commitment

· Integration Zone
Free Resource

Learn how API management supports better integration in Achieving Enterprise Agility with Microservices and API Management, brought to you in partnership with 3scale

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.

Unleash the power of your APIs with future-proof API management - Create your account and start your free trial today, brought to you in partnership with 3scale.

team collaboration ,architecture ,scm

Published at DZone with permission of Dennis Doomen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}