Chris Baus

Put it in writing

In the last year I transitioned from lone developer to project manager. In this role I find that I am called upon to make quite a few judgment calls both on the behavior and the architecture of the application.

I am really fortunate to work with a great team who I respect and are far better developers than I am, so generally this goes pretty smoothly. But occasionally, either due to my own biases or experience, I find myself in disagreement with a recommendation of one of the team members.

I have a simple solution to this problem. I request that the developer put the recommendation in writing. I do this for the following reasons:

We use an iterative methodology and don't specify every program element. While I am afraid being a Certified ScrumMaster might still be illegal in some Southern States, I am fan of iterative development. But there are cases where there is value in working out a problem in writing. It forces you to consider possibilities that a purely mental model might omit. If there is enough contention in a decision to actually cause a disagreement, it is a strong indication that the time spent working out the issue in writing will be a good investment. I also believe that being able to defend a recommendation or decision is a fundamental sign of maturity in a developer.

I try to hold myself to same standard. I recently caught myself in a discussion where I was arguing a point verbally in a way that was not fully formed. This left me feeling uncomfortable, and I forced myself to research the problem and present my option in a more educated way. Ultimately this puts the onus on the other party to define their position as well, and the end result is a more thoroughly considered solution.

Developers reading this may ask themselves, "Why do you insist that team members defend their positions rather than just trusting them? Don't you trust your own developers?" I do trust them, but in the past I've worked on projects with multiple smart developers, of one I consider myself, who all had their own ideas about the "right" way to do things. Chaos resulted. It wasn't that any one developer made a wrong decision, but we all made different decisions, and in a large scale software project this is a recipe for disaster (I'd also argue that this is why the philosophy of TIMTOWDI is seriously flawed, but I'll leave that discussion for another day).

I consider one of my roles to be the arbitrator of chaos, which ultimately means that every developer is not going to get to do things the way they want. This is a professional software development environment, and unfortunately it requires that developers perform their tasks in a manner that is in agreement with the ground rules of the project. That is why I highly recommend that developers unleash their experimental desires in a side project, and I'm even willing to turn a blind eye if they spend a few hours in the office working on it. I can fairly say that my side projects made me A LOT better developer.

But (there is always a but) there is also something to be said about allowing developers have it their way. Yes I still believe we could have gotten away with one less abstraction layer in app, but at the outset it wasn't worth making the developers miserable to enforce an architecture on them that they disagreed with. Happy developers are productive developers, and we had a lot of code to write.