As a software engineer teasing the edge of becoming more of an architect, the title of 97 Things Every Software Architect Should Know hit me with a number of questions I hoped the book might answer. Why 97? What about the 98th? And honestly after reading the third or fourth axiom and accompanying essay, I decided neither question mattered. In all fairness, I'm sure the title was meant to do exactly what it did and encourage someone to pick it up and take a look.
As I progressed and read each piece of advice, I found myself dog-earing each one I thought I might be able to apply and after a while I noticed that a little less than half of the book is now dog-eared. 97 Things Every Software Architect Should Know has made its way into the little shelf of materials I have right next to my desk.
Unlike the majority of other books about software engineering, this one doesn't focus on one topic but uses the shotgun approach to cover the most ground possible in 200 pages. As the editor says, "A great software architect needs to master both sides of the architect's coin: business and technology. This is no small challenge..." But the book he put together does a great job of rising to that challenge.
Monson-Haefel had a lot of help; each of the more than four dozen authors wrote their own material, donating their thoughts and advice to this effort. Each contribution was examined and edited and the best made it into the book. Articles cover such diverse topics as team building, communication, keeping customers in mind, ethics, and much more.
Among a few of my favorite axioms in the book are:
- "Stand Up!" by Udi Dahan - As software engineers, we find ourselves warming our chairs more often than not. But as an architect, you must communicate more effectively when explaining your decisions. "Standing up automatically communicates authority and self-confidence. You command the room. People will interrupt you less. All that is going to make a big difference to whether or not your recommendations will be adopted." says Dahan. Something we often forget when we stare at a computer monitor all day.
- "You're Negotiating More Often Than You Think" by Michael Nygard - We've all been through it. It's the classic question "Do we really need X?" and architects have to be ready to say "Yes, we do." and not back down like the engineers most of us actually are. As engineers, we're used to finding alternatives. Architects design things to be a certain way for a reason and shouldn't back down immediately. Negotiate instead.
- "Build Systems to be Zuhanden" by Keith Braithwaite - All too often we over-engineer things. Instead of using a hammer, which is a natural extension of your hand and arm to get the job done, it's really tough to pound in a nail with a computer keyboard. When someone uses the wrong tool, it demands the attention instead of the task you're trying to get done by using the tool. Your users shouldn't have to think about the tools you design too much. The goal isn't to make them efficient users of your tools - it's to help them get their job done.
There are 94 other nuggets of wisdom in this book. If you're on the cusp of becoming a software architect, I highly recommend taking a look and digesting the book slowly. It skips around quite a bit and took me the better part of a few weeks off and on to finish because I didn't want to skim and miss some crucial bit of information I might have needed. I think I'll be creating a one-page summary of the axioms of the book though and post it near my desk so I can remind myself of some of the great advice more easily.