Artful Minimalism

Nowadays you can buy development tools that incorporate tons of form-behind widgets and code generation that can produce web pages with pop-out scroll overs, call-outs, and just about every kind of special effect imaginable. Is all of this necessary?

Unless you are building a data entry form (which has its own special challenges) you are probably better off just to make sure your web pages meet a certain set of minimum requirements. After you have thrown together your page, run it through a few simple tests:

1) Window Resizing
Open your page in a browser and resize the window to various heights and widths to see what happens. Did your layouts get mashed? Do you need to change column widths from fixed to a percentage?

2) W3C compatibility
Submit your page to the free W3C verifier, just as a courtesy check to assure that your tags are all balanced and that your links are all valid.

3) Powersave Mode
Fire up a browser on a smaller screen device and in the browser options turn off the setting that allows the web pages to "set their own colors." Also go into the properties tab on your desktop and change the color scheme to a power saving configurations, with a black background and white text. Now open up your web page to see what happened. Do you need to remove some "color" tags to keep it legible?

4) Just The Facts
Go back into the browser settings and turn off automatic image loading. Refresh your web page. Does it still make sense with just the facts? Did you provide the necessary alt tags so that the user can still figure out where to click for navigation?

Sure, spinning flashing widgets are fun to view on your site. For all of about ten seconds. What stays as important though is the actual informative content that you provide. Try to make it work under all conditions.

Artistic Options

On your browser (under the Tools menu) you will find an item that says "options." And when you are developing code for your employer using the latest IDE, say Visual Studio, you can naturally set the look-and-feel "options." So how is it that within the software you create for your coworkers you left out the Options settings?

Maybe personalization is of less importance when you have two hundred clients rather than two million, but I also believe that a large part of the failure to personalize is deliberate scope restrictions to begin with. In other words if only twenty percent of the users need to see "purchase history" then we segregate it off to a separate screen. It's as if we pull the oysters off the regular menu since only five patrons regularly order them and they know how to ask for them.

Occasionally during design you will discover however that several groups of people work on essentially the same subset of data, although you will hear preferences expressed in terms of "I'd rather see it this way." I'd rather have a pulldown list. I'd rather have all the ship-to data on the side.

Heck, even restaurants that have a tightly limited menu allow you the flexibility to build other victuals given their ingredients. Go to In-n-Out and you can get a 4 by 4 or Animal Style without the carhop even blinking an eye.

Sometimes screens can be cleaner (and easier to code) if you design from the start with the idea of user-selected optional components or views. You will please more folks if you allow for personalization: expand their options!

An Artful Chunk

A fairly substantial design issue when planning the logical design of a database is how to "chunk" it. I don't mean vertical or horizontal partitions (for performance optimization) nor segmentation for security constraints. Rather, I use the term chunk here to signify how you associate large swaths of data with business processes such that you can restore a subset of the database.

Here's an operational example. You have several customers for whom you retrieve monthly or weekly datasets of new input, at random intervals for each customer. After you ingest the data you run three large processes to end up with a pick list of what to ship to each one. Say the whole process takes a couple weeks of elapsed time.

One day, after the second big processing step, you are informed that one of your customers sent you the data for the wrong store. What do you do now?

Planning for this type of occurrence takes careful attention to detail. Any manual data updates that occur outside of automated production need an audit trail so you may re-apply them after your data is restored. Large aggregation processes need checkpoints or staging tables so you may recalculate after a backout.

Making contingencies for large contiguous corrections, from the start of logical database design, is the artful way to safely chunk your database.

Artful Independence

If you design things from the start with testing in mind, then your finished system will be both stronger and easier to maintain. One way to accomplish this is to provide a "testing" checkbox (or menu pulldown) in your user interface. Doing so causes a complete design cascade in how you think about development.

It sort of provides you the same comfort level as if you were slipping behind the wheel in a Driver's Training car. It feels like authentic driving but with the added safety that if you forget to step on the brake you actually won't damage anything, as the instructor is watching out for you anyway.

It also allows you the wonderful opportunity to test production interfaces with a development-version of the backing database. Using this practice also promotes looser coupling between components. Of course, make it abundantly clear on the interface (say by changing the global form background color) when the client is in test mode.

This design method does incur some additional logical overhead. Usually you will set a "Testing" Boolean and have places where you evaluate it to set, for example, the database connection strings. This means you also have to provide both the production and development paths and parameters in your config fie.

The saving grace with this approach is that it pretty much clears you from the embarrassment of the all-too-frequent mistake of accidentally copying the development parameters into the production installation. So declare your independence from installation woes: code for testing from the outset and make the development configuration selectable from the interface.

Artistic Bonsai

A software developer faces dozens of constraints, from tools he may use, languages his employer supports, hardware and network availability, et cetera. But the largest constraint of software design is what lies between everybody's two ears: the capacity of their brains.

When you are initially designing a system and have finished your requirements solicitations and focus sessions, the first challenge that pops up is how to structure the functionality of the system into something that overlaps adequately to the mental capacities of those who will use it. They possess a certain capability to remember paths of navigation and where to set various field values to achieve specific business objectives.

Brain capacity also tends to limit the creative canvas of developers: you need to know enough of a subset of current technologies to be useful, yet you have to leave adequate "internal storage" to accommodate the intricacies of the domain knowledge for your employer and their industry.

Hence brain capacity planning is similar to bonsai gardening: the constraints force you to be artistic within the limits of your containers.

Artistic Arranging

In the windows-form world menu layouts are pretty settled, but no standard has emerged yet in the web-form world.

In a windows form try to keep your menus parallel to how Microsoft has theirs laid out: always a File menu at the farthest left, and a Help menu farthest right.

Use horizontal separator lines to partition out items of similar function, and be sure to enable hot-key shortcuts to the commonly used items. You should avoid a single item alone between separators. Menus shouldn't exceed eight or so items in any dimension (per pulldown or across) and shouldn't pop-out more than two deep, although I usually require a fairly serious reason for any pop-out after the first one.

Interfaces on web forms are tending toward an artificial "tabbed" approach. This works reasonably well provided you stay consistent with fonts, vertical spacing and presentation layout. More than three levels deep of tabs looks ridiculous; at that point its better to partition master pages into separate functional groupings. Avoid mixing horizontal and vertical menus on the same page and use a consistent menuing approach throughout your application.

Laying out menus is an art all its own. It's rather like playing rhythm guitar -- take the time to do it right and your menus should look good, be clean and intuitve, and stay in the background.

Artful Traceability

When you are in the actual throes of day to day production… after the development is done and you work out most of the bugs… it certainly is convenient to have some sort of end-to-end Traceability. The general concept is that every change in state or activity that has a material financial impact to the company (or its customers) should be traceable back to underlying actions.

The idea is somewhat similar to how an airline keeps track of its design and maintenance records. When a portion of the avionics fails during a landing it sure is nice to look back through the records to see what parts get linked where, and what has changed.

For example, at the end of the month you send an invoice to your customers. Where do the line items on this invoice come from: what atoms of work and activity (from a systems viewpoint) do they represent? Can you trace back from an invoice number back through shipping, fulfillment, ordering, and customer options?

Many time validation is just viewed as comparing the results of production back to the functional specs to make sure all of the business rules got implemented correctly. But validation should also be enabled for ongoing activity in a dynamically changing system, and this requires designing for traceability, from the very start.

The Art of Debt

I am often surprised how frequently developers fail to make database modifications simply out of laziness. Say you have a customer identifier for favorite color, and the values tend to be either blue, yellow, or red. Now say you add a new attribute to a customer and this attribute only applies to one existing subset that already exists.

Say only customers who put red as their favorite color also like beets. Should you add a new field (named beets) or should you split the "red" values in the existing field to "red likes beets" and "red dislikes beets." All too often I see folks go down the path of trying to squeeze additional information into the existing fields, "red likes beets."

Sure this requires changing less programming logic immediately but it also builds up "technical debt" by increasing the analytical complexity in the future. In short it trades elegance for immediately impressing the boss.

And this really gets to the crux of the matter in the Art in software development: do you shoot for pleasing the boss, or do you aim for a pleasing future?

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.

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?

Artistic Targets

Unfortunately it's exceedingly difficult to be both a great painter of landscapes and a great portrait artist. Or to be an exceptional travel writer and an author of thrillers. For similar reasons, developers end up specialized toward specific targets, across the dimensions of both deployable device(s) and targeted subject matter.

Sure some of this happens because we get typecast, but mostly this is due to time limitations: to excel at user interface design or a particular IT subject matter you must invest the effort to become totally immersed and familiar with it.

Yet as an artist, it also benefits a developer to expand his repertoire to adjacent presentation formats and related business fields. This is easiest to accomplish at the fuzzy borders of both. When you are designing a web page, see if you can also do a "light" or a mobile version. If you are working on CRM development see if you can stretch into analytics.

The main benefit of this -- aside from the obvious increased skill set to offer employers -- is that (like an artist) your new experiences will cross pollinate with the old, making both stronger. This is only beneficial to a certain depth however: if you attempt to be a jack of all trades you will find that you are a master of none.

Artistic Coupling

Creating software is similar to making a building but it is also somewhat different. You do need to start with a strong foundation of understanding the business rules and users of the system you are creating. This is usually captured in some graphical modeling. But once you start putting the pieces together the process should feel more like you are doing the interior design of a modular office.

Especially if more than a single developer is doing the programming, you want to leverage the concept of "loose coupling". This is a series of techniques, cautions, and an awareness that enables components to gradually change without breaking the interconnections between them.

One way to do this is to persist intermediate results to a database or file. A great advantage to this approach is that it's easy to mock up test data while you're still developing so that your work doesn't hold up anybody else. This does cause quite a bit of overhead however for high-activity classes or processes.

You can also provide loose coupling by adhering to strict standards in your object-design methodology. The types used on return values for methods and property set and gets should be strictly defined and maintained. If you need to provide more information back from a method than a simple system-type then define your own structure, but avoid using weak data types.

To maintain loose coupling you also need to avoid changing types after you have "published" them, as I described in this earlier post about maintaining modular compatibility.