Hello.

I have a confession to make: I’m a terrible software architect. There, I said it.

Then again, I don’t know why a confession is merited. Why would anyone expect me to be a good, decent, passable, or even mediocre software architect?

1. I did not study software architecture in University. There was talk of the architecture of systems, but I happen to be interested in real architecture, and I don’t recall any of my classes studying existing software architecture the way that architecture students study existing buildings or cities.
2. I did not apprentice to an architect for any substantial period of time. I did not learn a single, consistent, coherent style or approach from a mentor who was guiding both my work and my development at an early point in my career when I was focused on learning my craft. Sure, I learned things along the way, a lot of things. I’m a voracious student. But apprenticing is a different thing from self-directed study.
3. I have not worked on a single, substantial system over a long period of time. I haven’t worked on the Linux kernal for a decade. I haven’t toiled in the Bowels of Mordor on a proprietary enterprise operating systems for PCs. I haven’t been on a team that fought the legendary blue-pink wars only to lose to the cocoa outsider. I haven’t watched an enterprise’s core software evolve from COBOL to PICK to INFORM to J2EE.
4. I have read books about software architecture, but I haven’t taken a single book and rigorously applied all of its principles in unison to actual software, I haven’t attempted to truly and deeply absorb a single, coherent style of architecture through both study and practice.

I read blog posts. I’ve worked on other people’s software. I have all kinds of experience, some of it very valuable. But that experience is–let’s be honest with each other–ad hoc. It isn’t deep, structured and consistent. I might know of a “best practice,” but I might never have run into the problem the practice was designed to avoid.

All things considered, I’m exactly who I ought to be: A fellow who knows just enough to be dangerous. In fact, I know more than enough to be dangerous: I have a lot of experience writing tools for people who architect software.

the time before time began

There was, you may know, a time before Ruby and a time before JavaScript. In that primordial software ooze, there was a thing called Java. I worked for a company called KL Group, developing Java Tools. I joined them as the Technical Lead on a multithreading analysis tool. The product was called “Threadalyzer,” and it instrumented your live Java code and would look for “threading smells.”

For example, your code might sometimes lock A, and then lock B, and then lock C, fine. But if somewhere else in your code you locked B and then locked A, Threadalyzer would complain that you had a “lock ordering” smell: Perhaps, who knows, but perhaps one day you might have one thread lock A and another lock B, and then the two would become deadlocked as the first tried to lock B while the second was trying to lock A.

We did a bunch of stuff like this, and we ended up with a kind of Lint that watched your live code. (I’m still very inetrested in this concept, I like static code analysis but I daydream from time to time about what we might be able to infer about code and architecture smells from watching the code in action at run time.)

In the fullness of time I was propelled by the Peter Principle into the Development Manager job for a suite of Enterprise Java tools, and I spent my entire day working with incredibly smart people on tools that helped other people do architecture things.

But was I an architect? No. The Map Is Not The Terrain. The Tool Is Not The Product. I can tell you something about software and architecture, but if you want to learn architecture properly, you want to study architecture from an architect, not from a fellow who makes tools for architects.

This is an important dictum to absorb, because quite often in our industry we confuse expertise making tools with expertise using tools. We teach people that the highest expression of programming art is to write compilers, and to nobody’s suprise, many talented people would rather spend time writing programs that write programs, than time writing programs that solve problems.

It’s incredibly cool that I’ve produces software performance art like Ick and Rewrite Rails, but we should never confuse that experience with the experience required to build bankingsoftware that lasts.

If you want architecture experience, don’t go to a man who has devoted his life to making tools. Go to a woman who has devoted her life to using tools.

sandi metz

Go to Sandi Metz. Sandi is an architect. Like serious architects, she practices architecture. And she trains architects. And she has authored one of the best books ever written about software architecture. No seriously, I have read a lot of books, and while I may not be an expert architect, I am a fellow who can recognize expertise when he sees it.

Architecture is about software-in-the-large, and I believe that the measure of an approach’s value is the way the pieces fit together to form the whole. Taken individually, “POODR” is full of excellent tips, suggestions, patterns, and pieces of advice. And on that basis alone, I could easily recommend the book.

But there is a more important consideration. How do the pieces fit together? Our industry is plagued with the best practices disease, the thought that you can pick and choose practices and patterns, combining them into a FrankenApproach. This is not true. In architecture and design, the pieces fit together in important ways. They have interdependancies. They are coupled. That isn’t a bad thing!

Sandi’s pieces fit together. They are coherent. The lessons of one chapter inform the understanding of another. My feeling about this book is that it is more than a simple collection of wise observations and suggestions, it is an approach. And as such, it deserves study.

Skim it if you like. But better still, read it and commit to trying to apply it in a systematic way to real software in the wild. Commit to absorbing it as a lesson in architecture, not a series of workshops about programming.

You are interested in archtecture. Great! So learn architecture as architects do: In humble study from an architect.

post scriptum:

Practical Object-Oriented Design in Ruby contains a dedication: “For _____, who read everything first.”

For a very limited time, if you own or purchase “POODR,” you can use that name as a coupon to get a free copy of my own Ruby book, Kestrels, Quirky Birds, and Hopeless Egocentricity. Enjoy both books!