Saturday, November 24, 2012

Artistic Non

The non-functional requirements in software are rather like the things that we shop for when we go buy a car. We rather assume that it comes equipped with wheels, an engine, and brakes… these are functional requirements. Beyond that though we are looking for more: do we like the color, how it feels on the road, its gas mileage, its styling, whether to lease or to buy.

In substance the main non-functional requirements pretty much remain the same between large software projects:

- the software has to last ten years across a changing variety of display devices;
- it has to remain maintainable and enhanceable without it turning into spaghetti code;
- it should fail gently and has to recover fully;
- it needs a consistent interface that is intuitively easy to use.

Non-functional specs deal less with the “what” and more with the “how”. Hence the responsibility for defining their implementation tends to fall rather less upon the business analysts and more upon the IT management team.

- The philosophical battle over the non…

Just as folks can have finely honed sensibilities about their automobiles, a manager can argue the non-functional requirements from quite different perspectives depending on their personal philosophy.

Swaying the choice of styling is how the manager regards acts of creative destruction. If his experience suggests that leading edge regrowth ultimately compensates for the havoc caused by destroying legacy systems or jobs then he may bend toward less maintainability, static display devices, and higher levels of ease of use. He is focused more on the shorter term.

Some managers relish having a variety of platforms and tools yet others prefer a restrictive “vanilla” operation. Those tending toward variety may favor looser interface standards, but they may prefer a better corroborated sense of maintainability. They are focused more on organic growth.

Managers tend to sanction different turnover velocities, both with respect to employees and subsystems. It’s lease or buy in a different context. Those that favor a faster turnover may care less about maintainability but will tend toward common interface components. They are focused on punctuated evolution.

Finally some managers have a high aversion to risk. These will pay much greater attention to failure and recovery modes and request more thorough testing across the ever growing panoply of display devices. They are focused on safety. Generally then the vectors pointing the politics of “non” push along the four completely independent dimensions of creative destruction, acceptance of variety, turnover speed, and risk aversion.

What kind of car does your manager drive?

Wednesday, November 7, 2012

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.