[caption id="" align="aligncenter" width="500"][/caption]

I’m a big fan of ignorance. One of my favorite quotes goes something like “The one saying something is impossible shouldn’t interrupt the one doing it.” There have been a lot of times in my life where I was glad I didn’t know anything about the project I was doing beforehand because I wouldn’t have done it if I had. This is a very valuable way of looking at things, even though it can be hard to figure out when you actually do need to know something ahead of time so you don’t waste time or reinvent too many wheels. Every time I start a project I think about this balance but I haven’t figured out how to figure it out, if you get my meaning. In this post I want to talk about another benefit of ignorance, being willing to admit your own and how that can be a big help.

The other day at work we had our first design / planning meeting on a new piece of infrastructure. We’ve got enough different pieces needing to communicate that we’ve wanted to put a middle-layer in place for awhile now. Since we’re going to be starting our next big project soon, we all wanted to get this piece done before starting. In the meeting, my old friend ignorance played a big part. Specifically my personal ignorance.

The other 2 main Java programmers on the team and I were meeting with a programmer from our big vendor who also knows waaay more than I do about this middle-layer piece. It might have been annoying to my teammates but since I knew very little about how we were going to build this solution I kept questioning everything and having to have it explained to me. The reason I think this is a useful thing to do is twofold. One, we need to be able to explain this and justify it to everybody so having all of us understand is very valuable. I’m a pretty smart person overall so if I can’t catch onto something or see why we we would do something it’s a good bet others won’t either. The other reason is more important: explaining something to somebody who doesn’t get it forces you to think it through. If you take the first thing that comes to mind and just do it, you might end up with something more complicated than you really need or you most likely will have to redo parts of it later when you hit walls or are otherwise forced to think it through then. I don’t mind being the dumbest one in the room at all because of this. My personal preference goes along with the Agile/XP teaching of “Do the simplest thing that can possibly work” so I bring that along as well. After our meeting we came up with a really good design that builds on things we already have (reducing the amount of work needed), is easy to understand and justify, and will add real value to our system. It’s a testament to how well our team works together that we all contributed bits of work and knowledge and didn’t just rubber-stamp some design we all weren’t happy with.

Not being afraid to question things is a very helpful trait, even though some people might not like it. If you have questions about a design your capital-A “Architect” is proposing, do yourself and your team a favor and ask the question. Make people explain it. You have to be comfortable with the design of the things you build so if somebody else designs it, they need to make you comfortable. At the very least, that’s a courtesy to the team. At best, the design will get better as the designer has to think through answers to questions they might not have considered.

Thanks to the Dilbert Strip finder for helping me find this old favorite.