Friday, December 15, 2017

Artful Tool Use


A work acquaintance once posited “if we have the stupid people develop it, then it will be easier to maintain. If the smart people develop it then only the smart people will be able to maintain it.”

One of the classic management dilemmas remains how to select the creative workforce for a long-term project (or in software a neverending project) such that the system will not only stay maintainable but that the developers can accomplish the project in a subtle and efficient manner. It’s rather a deep question.

Your philosophy towards tool use and the Development Lifecycle may precipitate how you answer this question correctly in your surroundings. Imagine a chart with company strategy on one axis and expected system longevity on the other axis. Then we should ideally expect the mix of tool use and the level of employee expertise to look something like this:


Legend: HT = high tool, ME = medium expertise

At first glance this chart makes little sense: the ranges of expertise and tool use jump about and seem to lack any expected sort of gradient. This is attributable to the two dominions for when tools make a good bet: first when getting a system out fast has high strategic value, and secondly when time or money are likely to constrain your resources.

Similarly two situations require a higher level of expertise: when a system has a very specific focused utility and when the company needs the software to survive an expected future path of high business volatility.

Choose your tools and your creative workforce to match your company’s strategic plan. This is a key goal of I.T. strategy alignment and helps to avoid the dreaded swamp monster of impedance mismatch.


Wednesday, November 15, 2017

The Art in Empathy


The continual empathy of your clients is a key component of analysis. A separate entity from your sponsor, the clients are the people who will directly wield your software. Sometimes these folks overlap with the people who paid for the development and sometimes they don’t. Regardless you would do well to heed your clients’ desires as in the long run the clients keep you employed, rather than your sponsor.

This may strike a slightly odd chord, but it is akin to pointing out that you are more accountable for keeping your car running than the bank that lent you the money. All the bank cares about is that their loan is paid back with interest. But you will be the person driving your car and how you care for it and drive it determines how long the car will last. Similarly how well your project meets the needs of your clients will determine how long your software stays useful, even though your sponsor is providing the financing.

Amazingly enough the client enjoys relating their desires to someone who expresses a genuine interest in their needs and their working environment. You should try to discover what keeps the client awake at night: what are his worries. Nothing pleases a client like a designer who knows his workday life in detail, his daily routines, and what he faces in the way of competition and challenges in his office.

Analyze the big picture, not just the snapshot relevant to what you perceive as the scope of your project. Anticipate what the client wants: don’t wait for them to ask. Finally in those instances where you’ve identified a can of worms without a ready solution, consider what alternatives are available to monitor, mitigate, or manage the issue.

Interviewing for requirements seems simple enough, yet actually listening to a client discuss his desires takes a considerable amount of insight. You need to understand the sociology of his office and the things he wishes he had but doesn’t know how to ask for. Many times an employee is shy to relate his frustrations after finding that doing so in the past only set him apart as a complainer. You need to commiserate with him (without being smarmy or condescending) and then step back and independently think of ways to improve his working life.

Design extends beyond its up-front activity: once you’ve installed the initial version of your software you need to revisit the client to assess the full impact of your creation on his daily activities. The artistic thing to do is to create a system that your client appreciates long after you are gone. Continued empathy is the key for doing so.


Friday, October 20, 2017

Artful Hacks


Some I.T. personnel are as far apart as the East is from the West. Three metrics separate the developers from the management:

+ Easy to use
+ Fast
+ Proprietary

You see from management's perspective, software and file formats should be fast, easy to use, and universally available. In this way the company avoids being locked in to knowledge experts or particular vendors.

The developer however actually prefers the opposite: software and file formats that are cumbersome, resource intensive, and proprietary. In this way he can become an expert and increase his value to his employer.

So with both sides pulling in opposite directions what actually gets developed, what can possibly morph into physical being? Somewhere amidst the massive amounts of energy used in the politics and positioning of the two sides something springs up in-between.

Irrespective of the methodology employed or the layers of middle management helping to assuage differences, software developed in a corporate environment ends up partially complicated in the more obscure parts, just fast enough to get the job done, and reliant upon one or two inside hacks. It can be no other way.


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.