Fitting a changing world into a changeable machine
An electrical engineer and professor writes
I’m concluding that there are some limits to the amount of detail that we should computerize.
in response to changes in the real world that affect existing programs. While the example he started with (Daylight Savings) is a change that good system designers have anticipated, he reflected on some issues that I have been conscious of myself this week.
In the past couple of days I’ve had the opportunity [and the burden!] to redesign a map-drawing architecture while converting it from one programming language to another. I’ve been thinking about all the “real world” details that need representation in code, looking at things like Dates, Colors, Map Projections, Shapes, Pictures, Labels, Weather Data…. The many sciences lend insights which change the way things are best codified, and the state of my art is growing as well through time. For every one I need to consider: in which aspects should I follow/trust another’s design, which can I approach better myself (and still have time to squash enough bugs), what should I leave up to the human user to do on their own, and what should I leave until later!
Computing seems to force its binary nature out through the cracks of even a well-designed program or device. Don’t we often have to make a “take it” or “leave it” choice whether or not to invest time storing bits of life in a particular format or form factor? When taking a particular tool to use, it’s nice to know there’s potential for leaving somewhat gracefully later. (For example, iTunes stores a copy of its library data in XML for re-import or use by other programs. Then again, for the time being at least, if you forget your music store password you could be restricted from your encrypted purchases.)