Simplicity and Software Architecture

I'm always a bit behind the times so it was only recently that I found out that DevCon would be returning to the JW Marriott Grande Lakes in Orlando. I actually miss the Arizona setting. Sure, it's hot in AZ but it's a dry heat. Orlando is just as hot with the humidity but it does have better food going for it. While both cities suffer from a severe case of sprawl, there is something about the Sonoran desert that is seductive to me. Walking through the desert brush makes me more aware of life and the scale of it. It's my personal Total Perspective Vortex.

Not far from 101, just off of Bell Road, is Taliesin West, home of the architecture school started by Frank Lloyd Wright. Love or hate the man, I've always appreciated the design approach he brought to architecture. I think there is a lot to be learned from both his successes and his failures, perhaps more from the latter. The same can be said of many architects. Earlier this year Albert Harum-Alvarez invited a small group to tour the Julian Street Inn, a shelter serving the homeless population in San Jose. The facility was designed by Christopher Alexander, whose writing on design patterns have influenced not just architecture but the software industry as well. The tour was incredibly useful in understanding architecture on the many different scales it exists.

Inertia led me into my current vocation of software development. My avocation, on the other hand, is design, architecture, and construction. It seems natural to me then that I would be drawn to the ideas of Alexander and embrace the merger of art and information science. As a self-professed software architect I look for patterns in design at all levels of the system. Patterns exist not only in the user interface but also in the structure of the application logic and data model. I am constantly revising my practices in an effort to distill them into the essential - everything else is just a distraction. To that end, I'm not certain whether I agree or disagree with Joel Spolsky (and by extension Don Norman) when he derides simplicity. I think what he calls simplicity is what I would call a spare feature set. My goal, on the other hand, is not the reduction of features but rather making certain that each feature is implemented in as unobfuscated a manner as possible. Sometimes this means moving things into the data model, other times it means moving them out. Often it is an attempt to bring a certain aesthetic to the application.

There's a danger in confusing simplicity with simplistic or unsophisticated. In data modeling "simple" is often used as a synonym for "flat and wide" when it comes to table structure. In application design it is often used to berate scripting and UI control. I think we lose sight of the real meaning of simplicity as it relates to our applications. Simple is not a design methodology that describes how we put things together, it's a description of the user's perception of the end result. Sometimes simple methods are appropriate in creating simple results. Other times it's an engineering marvel under the hood to present the user with a "simple" view of the world. The software architect's job is to know when each approach is appropriate to the end goal of user simplicity.

Comments

[Jonathan Reff]

I was also unsure about Joel Spolsky's piece when I read it. It seemed one the major justifications for his "more is better" argument is that coming out with a new version of their product with more features has always led to an increase in sales. I then read the Don Norman piece, and it seems that this is the crux of the argument; not that more features make a better product, but that more features mean more sales. That may be true, but doesn't tell the whole story. What about the support costs, if those additional features confuse the users? And general satisfaction with the product after getting it home and using it for a while? Norman argues that those don't matter if you don't get the sale. I guess I'm thankful that I develop custom solutions, where the point-of-sale decision is not a factor.