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.

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!

Tuesday, April 18, 2017

Artistic Auditability

When you are designing software that updates data based upon business rules, or that creates new rows of data from somewhere else, be sure to pay attention to the creation of a useful audit trail. Yes this is more work than just updating the data or appending new records, but taking the care to do so has several benefits.

Folks in the financial or security industries use the terminology of Audit Trail to identify who accessed or changed which records, and when. A business audit trail however can be a more useful resource than for just tracking down suspicious activity.

Audit trails are useful both at record-level granularity and also at the file-level of detail. At the record level track the date and time that rows got created or updated, along with the name of the process performing the updates. Along with a timestamp, updates to master tables should also include the user ID and their IP address.

When you are making a global change behind the scenes programmatically to a file, create an easily identifiable annotation in a new, otherwise unused field.

If you are executing complicated business logic that determines activity that could have material impact to a customer, store the intermediate values along with the timestamp and version information; be sure to save this information for both affirmative actions and those that, in the end, result in no activity (sometimes the questions are about why things didn't happen).

For file level auditing it is often useful to have a logging table to track the batch processing of files, indicating a timestamp and overall record counts. Files being passed between systems should have a trailer record that contains both a record counter and a version indicator from the program that created it.

Audit trails assist in ferreting out performance problems and flaws in applications. They are also useful documentational research tools when a Support department needs to explain why a particular behavior occurred (or did not occur).

Thursday, March 16, 2017

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.

Wednesday, February 15, 2017

Artistic Teaching

Any company that has been around for more than six or seven years has had to deal with changes in the technology stack. Naturally this has serious implications to the clerical staff: those that actually deal directly with the customers. Of course most successful companies hire employees who are quick to learn anyhow. Yet when you have major system wide changes, it is of tremendous help to have a couple folks on board who are both astute at learning on their own as well as at communicating to and teaching the new technology to others.

It takes a certain type of personality to be comfortable with teaching coworkers: this is not like an elementary school teacher nor even a college professor. To be effective the instructor needs to be comfortable enough in their own learning abilities to stay "ahead of the curve" and hence secure in their position.

They need to possess patience for those who are slower to grasp new concepts, and yet appreciate the effort their fellow employees are making, and have a means to be continually encouraging. Companies that have found the keys to long term survival have also found how to keep their internal "teachers" engaged and on board.

Monday, January 16, 2017

Artful Champions

There's an old saying, "every social war is a battle between the very few on both sides who care and who fire their shots across a crowd of spectators." Analysis is very much like that. You have perhaps two or three managers who have different opinions about what your objectives should be, and a couple large groups of customers who care in the collective sense, but who individually just view your project with the valid skepticism of the small part it plays in their lives.

To really nail down the ethos, and for a large project to succeed, you need to have (or manufacture) a champion for each of the user, customer, and business interest groups. These champions needs to sincerely stand up for the benefits and beliefs of their group, and be gregarious enough to express them.

As you cycle through the balance points you then build up goodwill amongst the champions, and this enables you to negotiate concordance on the more difficult decisions.

This can be an especially hard sell: first, when a champion is less than sincere in standing up for their group. Secondly, when a champion changes employment, through their own choice or otherwise. And thirdly, when you can't get sufficient permanent heavy artillery support from a senior manager to resolve those instances where negotiations fail.

A solid 25% of full-metal Analysis involves the psychic steps to avoid these three pitfalls.