Wednesday, August 16, 2017

The Art in Algebra


Some aspects of software design feel very much like being mired in the depths of linear algebra. Once you solicit the requirements from the interested parties (when you think you know who is responsible for what) and when you establish the business rules that determine which user input you require for which circumstances, you end up with a hundred slips of paper that you somehow need to organize across three dimensions. Time to drag out the UECF matrix.

This is more of a mental process than an actual formula that delivers a specific solution. UECF stands for user-event component filter: it means organizing your system along the axes of roles (users), events (a customer places an order, an employee gets a raise), and components (what you conceptualize for the building blocks of your system). Or in object-oriented design we traditionally call these the use cases.

The essence of the problem is how to translate the use cases into various screen interface designs. This gets compounded not only by “who can set what” but also by the level of importance of each data field from the varying perspectives: we want important items at the top left on the screen, but what is important for one role may be superfluous for another. The usual answer is to wireframe a solution.

But this falls short of actually resolving the underlying algebra: how to organize screen elements as /reusable/ components. With wireframe modeling you end up with the blind men and an elephant analogy: each user describes the screen to appear correct but just from their limited exposure via their own responsibilities. The onus of standing up for a legitimate component view as it relates to the interface therefore falls squarely on the shoulders of the designer. You and only you are responsible for the design of the environment that will afford a proper care to the whole elephant.

Group logically reusable fields into a “tab” of a localized sub form or cordoned off area, where appropriate. Hey friend, the customer name, address, phone, and eMail are all a single common logical unit: group them together into a “control.” Of course the same is true for other groups of fields within your business. And create a matrix… do the algebra!


Friday, June 16, 2017

Artistic Test Harnesses


Modern object-oriented development is primarily cobbling small pieces of reusable functionality together. In the midst of development — during Spring training when you are hitting, running, throwing, and batting all day — you implement very specific business rules in small modules. Given certain input conditions and certain characteristics of the underlying data the invoker expects you to return the right properties or accomplish a persisted change in the data with a specified method.

Quite frequently the classes doing the heavy-lifting work behind the scenes without any visible interface to the user. How then do you make sure that your modules work properly? And how do you verify they work correctly under different conditions when called by different classes and when the underlying data changes? This job my friend calls for the use of a test harness.

A good test harness is like an automated batting cage where you can walk in, press a button for sixty mile per hour pitches, and have a machine throw consistent strikes.

Essentially a test harness is an ugly, quickly thrown together form with a handful of buttons and data-bound fields (or perhaps a data grid) that allows you full access to all of the ways possible to invoke your methods and set or get your public properties.

I like to use a tabbed interface when I’m building a harness; frequently I develop several objects simultaneously as part of a larger library and each tab tests the features of one of the objects. The complete form thus covers a large chunk of the library. Click a different tab to have a slower or faster pitch thrown toward you.

The best part about a harness, aside from the convenience it affords to unit testing, is that in the throes and craziness of implementation you can use it for quick and dirty fixes (invoking methods directly rather than bothering a fully implemented interface). Yes you can always take a shortcut and set debug checkpoints to carry out unit tests. But the extra flexibility and thoroughness afforded by a test harness, even though it requires an extra day to throw together, is always well worth the effort.


Wednesday, May 17, 2017

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!