Evangelizing New Software Architecture Ideas and Practices

Last December I spoke at the YOW Conferences in Australia on Why We Need Architects (and Architecture) on Agile Projects.

I wanted convince agile developers that emergent design doesn’t guarantee good software architecture. And often, you need to pay extra attention to architecture, especially if you are working on a large project.

There can be many reasons for paying attention to architecture: Meaningful progress may be blocked by architectural flaws. Some intricate tricky technical stuff may need to be worked out before you can implement functionality that relies on it. Critical components outside your control may need to be integrated. Achieving performance targets may be difficult and you need to explore what you can do before choosing among expensive or hard to reverse alternatives. Many other developers may depend on some new technical bit working well (whether it be infrastructure, that particular NoSQL database, or that unproven framework). Some design conventions need to be established before a large number of developers start whacking away at gobs of user stories.
I characterized the role of an agile architect as being hands-on; a steward of sustainable development, and someone who balances technical concerns with other perspectives. One difference between large agile and small agile projects is that you often need to do more significant wayfinding and architectural risk mitigation on larger projects.

I hoped to inspire agile developers to care more about sustainable architecture and to consider picking up some more architecture practices.

Unfortunately, my talk sorely disappointed a thoughtful architect who faces an entirely different dilemma: He needs to convince non-agile architects to adapt agile architectural practices. And my talk didn’t give him any arguments that would persuade them.

My first reaction to his rant was to want to shout: Give up! It is impossible to convince anyone to adopt new way of working that conflict with his or her deeply held values.

But then again, how do new ways of working ever take hold in an organization? By having some buzz around them. By being brought in (naively or conscientiously) by leaders and instigators who know how to build organizational support for new ideas. By being new and sexy instead of dull and boring. By demonstrating results. By capturing people’s imagination or assuaging their fears. Surreptitiously, quietly replacing older practices when reasons for doing them are no longer remembered. When the old guard dies out or gives up.

Attitudes rarely change through compelling discussions or persuasive argumentation. I look to Mary Lynn Manns and Linda Rising’s Fearless Change: Patterns for Introducing New Ideas for inspiration.

I take stock of how much energy I want to invest in changing attitudes and how much investment people have in the way they are doing things now. I don’t think of myself as a professional change agent. Yet, as a consultant I am often brought in when organizations (not necessarily every person, mind you) want to do things differently.
People generally aren’t receptive to new ideas or practices or technologies when they feel threatened, dismissed, disrespected, underappreciated, or misunderstood. I am successful at introducing new techniques when they are presented as ways to reduce or manage risks or increase productivity or reliability or improve performance or whatever hot button the people who I am exposing these new ways of working are receptive to. Labeling techniques as “agile” or “lean” may create a buzz in those that already receptive. But the reaction can be almost allergic in those who are not. The last thing I want do is to foster divisiveness. Labels do that. If I get people comfortable taking just that next small step, that is often enough for them to carry on and make even more significant changes. Changing practices takes patience and persistence. At the end of the day I can only convince, demonstrate and empathize; I cannot compel people to make changes.

Thanks to Joe and Jason…this blog is live again

It has been months since I’ve posted a blog entry. Why? Initially, life got busy. Then, in October my wordpress site was hacked. making it impossible to see or use my admin console. I went searching for fixes to this problem on the internet and at the wordpress community site, but didn’t find a whole lot of useful information. I was advised to reinstall a later version of wordpress and clear out my plugins…

I tried those suggested fixes. But I took conservative measures. Instead of reinstalling over my existing directories, I cleared out my plugins and only reuploaded portions of my wordpress installation. That did not fix my problem. I then backed up my wordpress database and tried a new installation of all wordpress files. I installed my new wordpress files into a separate directory (just to test whether it would fix my blank admin page problem). This did not work either. Little did I know that wordpress kindly redirects you back to your known directory path (which is conveniently stored in in the wordpress database) so it was accessing my corrupted wordpress installation directory structure, not the new installation.

If I’d only overwritten my existing wordpress directory with a fresh installation that would’ve fixed the problem. But I didn’t. Why? Because I thought I was being conservative by pointing a new wordpress installation of wordpress files to my database (and leaving the old installation intact). Big mistake.

I spent a day sleuthing my “blank” admin screen. I turned on php debugging. WordPress was getting redirected to a non-existent file (supposedly), but it seemed that the file was in my blog directory path. What was going on? I wasn’t sure. Never did figure out why that happens. (I really want to know about paths during execution of wordpress).

Next, I rooted around in all my directories after perusing some scanty but helpful documentation on the path and file structure of wordpress installations. When I did, I discovered a few suspicious php files in my wp-contents directory. I renamed they (hoping they wouldn’t be invoked, and that maybe they were causing the problem). But no luck. Gr.

Finally, I turned to my colleague and good friend Joe Yoder of The Refactory for help. Joe, who in addition to being a world class designer and Adaptive Object guru, also hosts a fair number of websites. He, along with his colleague Jason Frye, fixed my problem within the hour. First they installed wordpress and my database contents on their servers to check that my database wasn’t corrupted (wordpress ran just fine). Then they FTPed a fresh version of wordpress onto my server, and presto! I was back in business. They left me my old, corrupted version of wordpress in a newly renamed directory, just so it’s there in case I want to ever go figure out what was wrong.

I learned a few lessons during this very painful process: Advice on wordpress troubleshooting you find online is pretty sketchy. The “real” experts out there are sysadmin folks who’ve done enough wordpress installations and troubleshooting to know what to look for…and when they can, they reinstall a new version of wordpress rather than try to hack on a partially working installation. Not everyone has a Jason or a Joe to lean on. I’m glad I did. Thanks, guys!

I’ve been told by another friend that the wordpress’ execution model is pretty complex. Lots of paths and looking in different places…But after this experience, I’d be happy to help someone who is a guru, more fully document how wordpress works, what the database table structure and contents are, what the contents of subdirectories and when they are invoked, etc., etc. I’m serious about this.


I like to know how things work. I’m a designer, after all. I like to know how software works. I’d also like it if people who had wordpress installation problems had an easier time than I did (I got pretty discouraged). In my explorations, I uncovered many frustrated people who were asking for help and didn’t get very far. It doesn’t have to be that way.

If a deeply wordpress savvy person would like to talk about co-writing a small guide on “principles” of operation of wordpress, I’m game. I like to write. And explain how things work. Simply. So people don’t just have to “guess” and hack in as they struggle to fix problems. And with such a guide, I believe life would be for those who want to blog as well as know what’s going on, under the hood.