fiat lux

Another short entry. The short answer: because now you both have to observe the old behavior and respect the history.

Many system designers ignore the fact that a system is a historical construct. No, we are not talking about some 1970s French phisolophy-cum-literary criticism stuff. But truly, a system is not just designed. It’s formed over time. Many systems, when they finally reach to the stage where they become inadequate and even burdensome, were at first designed with clear mission and structure. But many small changes have creeped in. Many last-minute changes, or small tweaks (so as to make the system work), would become a norm.

Any redesign must honor the old system’s total functionality, and such totalness is very detailed and hard to figure out.

Of course another way of redesign is to refine the mission, the problematics and the solution/functionality of the system. But that usually involves more timely rethinking. Any rethinking done with haste or haughtiness is often doomed to be a design even more inferior to the old one.

As a programmer, I’d say it’s the debug, and the quick fixes and tweaks that comes along with the debugging process, that lubricate a software system. Those lubricants are added over time. And that’s why I said a system is a historical construct. Many fixes and tweaks do not belong to the initial thinking (the design stage). They are not to be accommodated in an abstract model and often pop up only in the running stage. It’s tremendously challenging for a rethinking (rearchitecture, refactor, reform) to accommodate them.

The implication here is: be wary of the tweaks and quick fixes that will be part of a system’s life. A system that absorbs and digests those tweaks better will usually have a longer life (ironically, that also makes it harder to regenerate [ie. for the system to start anew], but that’s a topic for another day).

lukhnos :: Sep.05.2007 :: tekhnologia :: 3 Comments »