Architect Hubris
07 Apr 2007My day job has morphed into an architect role as of late. It’s quite a change going from the consumer of designs to the maker of designs. I’m also rubbing shoulders with folks who don’t program for a living and it’s quite interesting to hear their views about how the implementation of a particular design should proceed. I once heard read somewhere that you should beware the non-coding architect. To be fair, you need people (make that smart people) who’s primary duty is to design and align the major elements of a project. But I don’t think they should be entirely removed from “feeling the pain” of their decisions either. A coding assignment now and then helps to realize the issues up close and personal.
One thing I’ve noticed working with other software architects is that they sometimes try to solve too much in their designs. Since most of my experience has been at the other end of the food chain, I’m use to working out the issues as I encounter them. I read a great quote from Jeremy Miller today that says it far better than I could.
Watch out for Architect Hubris. The idea that you can foresee all possible points of divergence ahead of time is flawed. You need to be tailoring your framework to providing value in exactly the way that the business functionality requires. The best way to ensure that your framework fits its actual usage is to grow the framework organically as you develop real functionality. In Ordering Software Construction Tasks, I tried to argue that the strategy of building the architectural framework first, then developing the actual business functionality second can easily be a delayed time bomb. Getting the perfect design upfront can be a boon, and sometimes you’ll be right, but on the whole you’re going to be better off measuring your design as you go with real world feedback. Thoughts on Building Pluggable Frameworks
I’ve got a lot to learn about my new role. Hopefully I can do it without losing the respect of my fellow coders.