Fighting Dogmatism with Fresh Perspectives

Pair-Programming

It is unfortunately easy to forget the depth of the lessons that have led us to our current software development practices. However, I’ve found it’s similarly easy to be forced to recall them — work with someone new.

I’ve had the pleasure this summer of working with two folks new to AO: Nick Reynolds, an intern who will be returning for his senior year at MSU shortly, and Jesse Hill, an experienced software developer with an especially strong background in mobile and Java. Both have taken to our ASP.NET MVC web application development project swimmingly. One of the things I’ve really enjoyed about working with these two is that they ask questions — good questions that force me to recall the important lessons that have lead to my current practices on this project.

Hidden Dogmas

Over time, best practices can become dogma. At one point, there were good reasons to do X or use Y, but everyone has forgotten them. We just repeat our practices like mantras: “Use mocks. Write system tests. Use dependency injection! Single responsibility!

A litmus test for a dogma is to ask someone (or yourself) about the value of the tool or practice. There should be a value — a reason why — and it should be applicable. If not, there may be a problem.

The questions posed by fresh minds often target these areas, and being called to account for the value of our common practices helps keep them from becoming unquestionable, dogmatic cruft. Be willing to entertain these questions, and you’ll be rewarded with a refreshed understanding of yourself, and you’ll give your team a genuine opportunity to see for themselves the value of the tools and practices you employ.

Your job as the teacher is not to drill highly-distilled practices into eager minds, but to share past and present experiences in all their depth and richness. Walk through the “what-if” scenarios, and trace information back to the books, blogs, and situations you learned from.

Dogmatic practices are a hallmark of dead-end developers. We owe it to ourselves and to our teams to eradicate them.

A Dogma-Fighting Culture

Dave wrote a little while ago about thriving on criticism when you make mistakes. It’s an awesome post, and you and your whole team should read it.

I would like to extend that thinking to cases where something isn’t wrong, or bad, or broken, but simply not as good as it could be. Encourage suggestions of alternative solutions, and accept critical observations well. Freely admit when your solution doesn’t work out as well as you’d hoped, and be willing to do something about it.

At Atomic Object, our practices (including pair programming and changing projects regularly) place people with different experiences on project teams, working closely together. I highly value the opportunity to both challenge assumptions and have my own assumptions respectfully questioned, despite the discomfort that sometimes accompanies such challenge.

Our culture of personal accountability and transparency also help fight dogma. When others are able to see what you’re doing, and when you own up to your decisions, it’s hard to escape needing to explain the value of your choices.

Nick, Jesse, and future teammates — keep the questions coming. There’s no room for dogmatic software development practices here.

 
Conversation
  • What about open vs. closed offices vs. something in between?

    http://blog.idonethis.com/post/30585678147/reconsidering-the-startup-open-floor-plan-office

    It looks like Atomic Object has an open office plan. Have you considered any alternatives?

  • Comments are closed.