I read somewhere that 85 percent of the population will 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 book for this year. I do read a lot, and not all of it's about programming. I also tend to take a very broad view of what counts as a book about my field to make sure that I can count myself in the other 15 percent of the population.
So, let me recommend a book that might not, on the surface, appear to be about programming at all. The book is called How Buildings Learn, and it's by Stewart Brand. Stewart was, for many years, associated with The Whole Earth Catalog, which was often an excellent source on software and how it was used. How Buildings Learn is about how buildings change over time to meet the demands and needs of their occupants. At least that's what it's supposed to be about. What it's really about, of course, is software maintenance. Which makes it a very important book.
I've probably harped on this before, but we all spend far too much time worrying about development costs and reducing the money spent on building systems. The last estimate I read suggested that for every dollar spent in development, you (or your clients) will spend six dollars in maintenance. This was also back when it was estimated that the average computer system 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 and pretty 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 are made to the system that gradually bring the system in line with the users' real needs and wants. Done well and done with care, even systems that users hate can be transformed into tolerable tools. One of the reasons that I liked the book so much is that Stewart feels that maintenance is primary, something that I feel is very true of computer systems also.
Stewart also describes how buildings have to coordinate changes between the parts that can change quickly and the parts that can change only slowly. These components must also be aligned with the many changes that occur frequently and the few changes that occur over long periods of time. Frequent changes must be easy to do, and the infrequent changes can be more expensive. As database developers, we also need to recognize the stuff that changes frequently and the stuff that changes infrequently. As an Access developer, you know the benefit of creating table-driven systems so that changes and additions can be made just by making a new entry in a table. You also know how hard it can be to make a simple change like converting a numeric field to text or lengthening a field by 10 characters.
The book also distinguishes between "high road" and "low road" architecture. "High road" describes buildings that are designed and built for a purpose. "Low road" describes buildings that are essentially throwaway, built by no one in particular and modifiable with a sabre saw. I'm sure that you've built both kinds of systems: projects with lots of design documentation and years of work, systems with no documentation that were built in days. Neither kind of system is inherently good or bad, and both have a place.
How Buildings Work also provides a cautionary tone on designing buildings that fight change. Change is inevitable, and buildings that work with change will succeed and last much longer than those that won't change. They'll also be loved. As we build our applications, wouldn't it be nice if they were loved?
Actually, you're guaranteed that at some point your system will be loved. When your system is finally replaced with some other system, you can be sure that your users will -- finally -- start to speak fondly of your old system.