Re: Architecture the Accelerator
Posted: Feb 24, 2005 3:47 PM
> > I wouldn't say that any of us should reduce quality so
> > much as be satisfied with varying degrees of quality
> > depending on the circumstance. Let me give you a
> > metaphor in the building architecture world.
> Are you implying code quality is a linear measurement we
> can evaluate without considering its context?
> > ... By contrast, in the lobby of that same hotel there
> > was a staircase that was nicely curved and carpeted. The
> > railing was wooden and polished. It was a higher
> > set of stairs.
> I don't agree--I believe context matters. Fitness for
> purpose, IMO, is a first order factor in measuring the
> quality of these stairs. If you're trying to evacuate the
> building, I'm fairly sure you would prefer a non-skid
> surface and steel safety rails over the polished rails and
I agree with you about fitness for purpose, especially if you mean business purpose. Quality is subjective, so it is not something you can objectively measure on a linear scale. But you can measure cost that way. You can count how much money you've spent.
The way I map the stairs metaphor to software is via cost. The hotel is willing to spend more money building the carpeted stairs in the lobby than they concrete emergency exit stairs. The lobby stairs' business purpose includes 1) providing a commonly used way for customers to access the next floor up or down, 2) impressing or at least not repelling customers when they walk in the door. The hotel is willing to spend that extra money because they see the return on investment.
Moreover, the hotel is willing to spend more money over the lifetime of the lobby stairs to keep it clean compared the emergency stairs. I kept seeing cleaning people using the emergency stairs to move between floors, but I never saw them actually clean the stairs. The emergency exit stairs were downright filthy, because they hotel didn't see a compelling return on investment for keeping them any cleaner. The cleanliness of those stairs made little difference to the customers, because most customers never saw them. And during a real emergency, when the customers would see the filth, they wouldn't care. They only quality they would care about at that time that the stairs enabled them to get efficiently and safely out of the building.
Keeping code clean by refactoring and good test coverage costs money, just like keeping the stairs clean. And although quality is subjective, I find that the more I invest in refactoring and writing tests the higher quality code I can produce (though eventually I start getting diminishing returns). In other words, the more time/money I invest, the better factored the program gets, the more consistent the naming, the more focused the classes and methods--the better the code would score when judged on all the usual OO best-practice heuristics.
I once worked at a company that created equipment for semiconductor manufacturers, and we occasionally had to go into "clean rooms" to do testing of our software. We had to put on white outfits, booties and shower-cap like hats, because the clean room requirements were to have only one particle per thousand or million (I don't remember the exact number). The floors in those clean rooms were pretty darn clean, but it cost a lot of money to get there. The business was willing to invest that money to get that level of cleanliness because they saw a return worth the price. Compared to the clean room floor, the lobby stairs in that Chinese hotel were filthy.
I think it is more important to focus on the quality/cleanliness of class and method interfaces than implementations, and on published APIs than on internal APIs. I spent a lot more time trying to maximize the usability of the ServiceUI API, for example, than I do the internal Artima APIs. I also suspect it you get a better return when focusing on quality when establishing architectural conventions that will live a long time than when fitting things into an existing architecture, because it is easier to clean up cruft stuck in-between the struts of a solid, well-crafted architecture than fixing a badly formed architecture. In fact I have observed that this is one way a good architecture helps me move quickly: it allows me to whip something out to meet a deadline, because it keeps the system standing while the cruft is in there, and it supports me if and when I go in to spend a bit of time/money to rework that cruft into something more polished.