I read somewhere that 85 percent of the populationwill go the whole year without reading a book about their field of work.Hopefully, the collected annual issues of Smart Access will count as your bookfor this year. I do read a lot, and not all of it’s about programming. I alsotend to take a very broad view of what counts as a book about my field to makesure that I can count myself in the other 15 percent of the population.
So, let me recommend a book that might not, on thesurface, appear to be about programming at all. The book is called HowBuildings Learn, and it’s by Stewart Brand. Stewart was, for many years,associated with The Whole Earth Catalog, which was often an excellent source onsoftware and how it was used. How Buildings Learn is about how buildings changeover time to meet the demands and needs of their occupants. At least that’swhat it’s supposed to be about. What it’s really about, of course, is softwaremaintenance. Which makes it a very important book.
I’ve probably harped on this before, but we all spendfar too much time worrying about development costs and reducing the money spenton building systems. The last estimate I read suggested that for every dollarspent in development, you (or your clients) will spend six dollars inmaintenance. This was also back when it was estimated that the average computersystem was around for about six years. As the Year 2000 crisis demonstrates,the average computer system lasts considerably longer than that.
Stewart discusses how buildings improve over time andpretty much describes the effect of maintenance on computer systems.Frequently, new systems aren’t so much implemented as inflicted on their users.As users complain and interact with the systems department staff, changes aremade to the system that gradually bring the system in line with the users’ realneeds and wants. Done well and done with care, even systems that users hate canbe transformed into tolerable tools. One of the reasons that I liked the bookso much is that Stewart feels that maintenance is primary, something that Ifeel is very true of computer systems also.
Stewart also describes how buildings have tocoordinate changes between the parts that can change quickly and the parts thatcan change only slowly. These components must also be aligned with the manychanges that occur frequently and the few changes that occur over long periodsof time. Frequent changes must be easy to do, and the infrequent changes can bemore expensive. As database developers, we also need to recognize the stuffthat changes frequently and the stuff that changes infrequently. As an Accessdeveloper, you know the benefit of creating table-driven systems so thatchanges and additions can be made just by making a new entry in a table. Youalso know how hard it can be to make a simple change like converting a numericfield to text or lengthening a field by 10 characters.
The book also distinguishes between “highroad” and “low road” architecture. “High road”describes buildings that are designed and built for a purpose. “Lowroad” describes buildings that are essentially throwaway, built by no onein particular and modifiable with a sabre saw. I’m sure that you’ve built bothkinds of systems: projects with lots of design documentation and years of work,systems with no documentation that ere built in days. Neither kind of systemis inherently good or bad, and both have a place.
How Buildings Work also provides a cautionary tone ondesigning buildings that fight change. Change is inevitable, and buildings thatwork with change will succeed and last much longer than those that won’tchange. They’ll also be loved. As we build our applications, wouldn’t it benice if they were loved?
Actually, you’re guaranteed that at some point yoursystem will be loved. When your system is finally replaced with some othersystem, you can be sure that your users will — finally — start to speakfondly of your old system.