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.

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.

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!