Artful Heroics

Management tends to overlook the quiet heroes; this is especially true in Information Technology. When the hardware fails -- the server crashes hard -- the folks who patch everything up and get it working again get a slap or the back, accolades, and a nice mention in their performance review. But the guy that quietly monitors performance every day, cleans up the old files, optimizes indexes, and releases old record locks, goes completely unnoticed, even though his work keeps things running smoothly.

Naturally since I.T. folks are smart and recognize this, you tend to find that they decamp into two philosophical groups. The first group maximizes their perceived value by purposefully being lackadaisical in maintenance, all the while squirreling away the tricks they know for recovery. Then they can spring out of the phone booth in their Superman suit when the time is right to be the eventual heroes.

The second group though, the Artful Heroes, quietly and unselfishly keep plugging away, patching and making small unnoticed incremental improvements to keep things running smoothly. For they recognize their reward when they look into their manager's eyes and see the acknowledgment that their manager indeed knows their value overall.

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.

The Art in Conception

Once you have sold a vision and made the commitment on behalf of yourself (or your staff) to actually create a product, the magic of conception unfolds. Somewhere deep in your conscience you have the basic concepts of how the final product will look and behave -- in other words you've got the general parameters of a target -- but how will you get there?

Rather amazingly in our modern gadget-driven world, the best approach is still to sit quietly in a nice sunny room with a window, a pencil, and a pad of paper, and begin sketching. Draw out your concept, write down your concerns, and show all of the pieces and how they relate to one another. Make lists of the things that you need to store.

Then you're ready for some more presentable modeling. I usually like to start with three diagrams: a state model, a sequence diagram, and either an entity-relationship diagram (if you're focusing more on the data structure) or a UML diagram (if you're focusing more on the objects). The purpose of all this however isn't actually to convince anybody of anything, but rather to help clarify your own thinking and to pique new insights.

Now put the diagrams down and go out for a walk. Or better yet do the diagrams on a Friday and spend the weekend exploring around town.

On Monday look at your drawings with fresh eyes. What did you overlook? Things always turn out to be more complicated than you initially anticipated. Who do you need to talk to in order to clarify matters? Are there more robust ways to create your solution? Something that might be more flexible?

This first couple weeks of a project are magical but they are also a bit frightening. We make architectural decisions that fairly rapidly get set in concrete. So don't rush yourself through this aspect of design -- consider all of the possibilities. Then after you've nailed your design parameters comes the real stickler, user interface design.