Artistic Cycles

Some software components have nothing to do with business requirements per se, but are rather reactionary coding after the fact to handle the daily, monthly, and seasonal cycles of production, or to accommodate the processing of one item at certain times against others. These timing interactions can rarely be foreseen during the design stage of a project.

Hence, make sure all processes can be safely paused or scheduled. Make table entries when a process passes though various stages, so other processes may be aware of its status. Plan for processes to be stopped, rolled back, and then restarted. Finally, allow for priorities so that specific components of work can move through production at different speeds.

A design artist knows it rather makes good sense to allow leeway for controls of production cycles even without soliciting their requirement.

An Artistic API

Application Programming Interfaces, or APIs as they are commonly called, present interesting design challenges, both from the perspectives of a producer and from the point of view of the chain of consumers.

The immediate consumer is a developer who wants to use a certain service (say for example a geography API). His concern is that he gets consistent results returned in a structure that is both easy to parse, and robust enough to handle a variety of error conditions. The second consumer is the business analyst, who would like any API's that the staff use provide adequate documentation and that subsequent upgrades to the API avoid deprecating functions. The third consumer is a development manager, who has concerns that API use remains in a controlled enough environment that he can hand off development to future staff, as well as avoid vendor lock-in.

The challenge therefore is how to offer powerful APIs that aren't fragile. Some of the design variability involved revolves around the choice of granularity: do you just provide a couple of methods with dozens of properties, or do you provide a dozen methods each having two or three properties?

Ah, so here comes the magic. You see, the consumer who is the developer prefers a small quantity of functions with numerous parameters: once he actually makes the effort to learn them, they are easier for him to remember and the fragility affords him job security. The analyst prefers a middle course, a dozen functions each with four or five properties, as the documentary chunks are more easily absorbed. The manager prefers a hundred functions with a couple properties, as he can develop separate human resources to digest subsets of the entire functionality. So think now: as the developer, who is actually the "buyer" of your API?

An Artistic Haircut

In the quest to stay ever current of technology, companies constantly face the challenge of deciding whether to further complicate old, existing systems, or whether to scrap the old technology entirely for something new. On first inspection it is often difficult to appreciate the extent of effort that has been invested in a legacy system. Whereas on the surface the risk here would seem to be a straightforward analysis of uncertainty versus potential reward, the deeper diagnosis actually revolves around customer service issues.

Most likely a high percentage of your existing customers use only a small contained core section of your legacy system. You want to target the 70 percent or so of these customers who you can move to the new system with the least amount of risk. Realistically however you should prepare both the management and you staff that the process will essentially give your revenue a 30% haircut: it is simply unprofitable to convert everyone away from the legacy system, as after the new system is close to code-complete it becomes too costly (primarily for your customer support and technical support staffs) to maintain the other 30% on the legacy.