Last year I talked about lessons learned from architecture reviews at JAOO 2007 and Markus Voelter from Software Engineering radio interviewed me. You can listen to our conversation.

I’ve experienced both sides of reviewing. Early in my engineering career I presented the design of a universal linker to an external reviewer. I was scared to death that the reviewer would pick apart my design. I was relieved when my design was blessed, but annoyed when the reviewer doubted my ability to deliver on time. (I delivered, but in hindsight I could see why he and my management doubted me–as a new engineer I was working solo on a critical project…I just didn’t know what I couldn’t do).

These days, complex IT systems are rarely understood by a single engineer or architect. Teams come together to create complex software systems. Technical challenges can be enormous and the “tricky bits” involve the subtle interplay of business and technical design decisions. The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters.