Tuesday, September 12, 2017

Artful Commitment

People arrive at the ocean of project management from various rivulets of experience. Some have navigated programming or quality assurance while others set out with a business management education. Regardless of how you get there, once you have responsibility for overseeing the movement of creative team processes you find yourself in the delicate position of asking people to do things.

To a certain extent folks enjoy being challenged and pushed. They dislike, however, being stressed and overworked. The trick is to find the sweet spot where you commit them to the fair amount of pressure. At the same time folks have their own personal quirks and either tend to over-commit themselves or alternatively play up the amount of time that they are being productive when they are actually socializing instead.

It’s sort of management science: if you don’t assign the work then who is going to do it? Obviously you want to show some efficiency in completing the workload, but you also want to maintain good morale. This engages several competing foci and proves to be a riveting point in project management.

And I mean riveting in the sense of steel beam construction: the rivets only go through the steel in strategic locations, and for good reason. A rivet in the wrong place — too close to other rivets or adjacent to a concentration of shear — will weaken rather than strengthen a structure.

It’s your job when you are managing a project to rivet the team together to make sure that all of the pieces, players, and components are carrying their load under equal stress.

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.