If talking about music is like dancing about architecture, I’m not sure what that makes talking about architecture, but talk we did, about software architecture rather than the bricks and mortar kind. Last Wednesday I participated in Part 2 of the Architecture of Open Source Applications webinar run by Smartbear Software and the Software Quality Connection. The other participants were Greg Wilson, my co-editor; Margo Seltzer, who co-wrote the chapter on BDB, Simon Stewart, who wrote the chapter on Selenium; and Emil Ivov, who wrote the chapter on Jitsi.
Read on for some of their insights.
You need that visceral sense of failure. – Simon Stewart
Each panelist talked about what surprised them, or what they learned, in the process of writing their chapter. Emil talked about not “expecting the unexpected”; he learned that you should just go with what needs to be done at the time and be ready to change it later, rather than trying to plan for every contingency up front. Margo talked about teaching students how to read source code, and about reading the Lions’ commentary on Unix as a student herself. Simon was surprised that he’d never sat down and written out his application’s design choices before. Greg discussed being pleasantly surprised that self-publishing was easier and quicker than legacy publishing, and I talked a little on that subject too.
Questions from the audience elicited interesting comments.
How can you distinguish good architecture from bad architecture? Simon suggested that the more you need to know about a system to make change to it, the worse the architecture is. Margo said that well-written software is easy to read; if reading it makes you angry and frustrated then the architecture is bad. She also said that good architecture disappears into the code (kind of like how good novel structure disappears into the story — my analogy, not Margo’s). Greg observed that open source code can be like a third world city, with slums abutting nicely manicured neighbourhoods. The result is that most developers stay in the tidy parts of the code and the messy areas are neglected. According to Simon, it takes a strong leader with plenty of nerve to clean up those messy spots.
Sometimes problems are solved by people who don’t properly understand the problem. – Margo Seltzer
Does good architecture always go hand-in-hand with good code? Can you have good architecture which is badly implemented, or bad architecture implemented with good code? Margo proposed that you can have good architecture implemented badly, but that it’s easier to replace bad code if the architecture is good.
The full webinar is available on-demand, with tons more interesting discussion of software architecture, computer science education, and the best pub in London.