Saturday, May 12, 2012

Artful Culture


In some development efforts, our goal is to deliver software that is "fun." In other words the purpose of the software is to Entertain. In most workplace environments however the goal is to deliver software that helps people get stuff done; in other words the software has Utility.

In actual cultural practice however, most developers strive to make their software a little bit of each: you want to make your software "fun enough" that folks don't get bored out of their skulls when using it while they are getting stuff done. In fact, you generally want to hit a certain sweet spot such that in addition to its Utility, what you produce is:

Culturally Appropriate, Fun, Inexpensive, Courteous, Accurate, Responsive

Unfortunately these "cultural" aspects of development are seldom if ever captured in an Analyst's "Requirements" document. They also fall a bit outside the realm of what IT management might normally consider as platform based "non- functional" requirements.

How does this culture get baked into the software then? Well it usually takes culturally aware developers.

Monday, April 16, 2012

Artistic Utilities


One item designers consistently overlook during the redesign of a legacy system is capturing the hundreds of small utility programs in use to perform the mundane and necessary dirty work: one shot fixes, bug patches, cyclical clean up, ad hoc requests, et cetera. I suppose the consensus might be that the old utilities should be irrelevant for the new design.

Just the fact they exist however shines a light into the dark corners of workarounds and the prolific ability to bend to the flexibility of user demands and their processing errors. When redesigning a system therefore, at least pay attention to the general circumstances and conditions where utilities get invoked, and plan to support a similar panoply of solutions in the new environment.


Tuesday, March 13, 2012

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.