Call me old-fashioned, but a byte used to be worth eight whole bits, and every one of those bits represented a choice: yes or no, present or absent. OK, maybe not actually a matter of good or evil, but nonetheless a value proposition.
And the eight bits in a byte, combining to represent 256 distinctly different possibilities? One could build a universe from such wealth. Our respect for the value of data showed in the design of data structures, each like a little Swiss watch with every part of the mechanism there for a reason. One cant help noting the contrast with todays vast warehouses of structure that are too often filled with mostly empty crates, a problem that 64-bit platforms may magnify.
In the long run, what could be more important than keeping our data repositories rich in information value, rather than letting the good bits be swamped by distracting redundancy and noise?
I have a real problem, therefore, with the way that valuable bytes are wasted by sloppy software design. Yes, I know that hard disks are cheap, and I know that processors are fast, but wasting bytes means eventually wasting the time of skilled and valuable people. Someone, someday, will have to decide whats not worth keeping anymore.
In the same way that PC makers are now being challenged to help keep their discarded products out of landfills, I wonder what would happen if software developers had to confront the cost of cleaning up the waste that their products spill all over our IT spaces? Better to put the intelligence at the earliest possible point in the process because the cost of eventual cleanup is one that goes up, not down, with time.
Perhaps Im taking this too personally, a side effect of being stuck for two nights in a hotel room with terrible phone lines: When was the last time you saw your modem fall back to a 7K-bps connection? It certainly does remind a person of the need to weigh the value against the cost of every byte that has to go from Point A to Point B.
Page Two
But even without that personal grudge against byte bloat, Id have been struck by the irony in a recent tutorial article on the IBM developerWorks Web site that praised, as if it were a brand new productivity tool, the ancient uniq (as in “unique lines”) filter utility for processing simple text files. What really caught my eye was the tease for that article that appeared on the developerWorks Linux home page: “Got logging nightmares? Save time and headaches by removing duplicate lines with uniq.”
There are layers upon layers of lessons to be taken from that perversely cheerful question. First: How many systems are busily generating log files, even as we speak, that no one will touch except to delete them when they take up too much disk space–so that they can start accumulating data in the dark, all over again?
Second: Why are logging functions in so many platform software products so crudely implemented, merely spewing out mostly uninteresting data instead of being written with a decent set of options for what gets recorded–and for how long its to be kept? Imagine the irony of deleting a years worth of logging data because its taking too much space, only to have a problem in the next week–and having only a weeks worth of logs to review. If logging is worth doing, isnt it worth doing well?
Theres been a lot of discussion lately about whether IT is crossing a threshold to become a more mature infrastructure of commodity technologies, rather than a white-hot crucible of disruptive innovation. Theres something to be said for the proposition that people are becoming more inclined to feel that what they have is good enough.
But if were going to live with a product for a longer time before we consider it obsolete, shouldnt we look for products that wear well over that longer-lived relationship? Designing software, not merely to look good over a 90-day trial, but also to age gracefully, needs to become a priority during design. Lets make every byte count.