Outcomes vs. Process

Some years ago, I worked at a couple of companies (EMC Controls, Digitrol/ITP Systems) that were in the process control and factory automation business. They have both since gone out of business, or been absorbed into other corporate entities. I bring this up as a way to segue into the topic of this post -- process vs. outcomes.

These companies were in the business of supplying process control to industrial customers. What we controlled was process, and by controlling the process, we affected the outcome. There is no such thing as 'outcome' control. That's not to say that there are not outcomes -- it's just to point out that in order to achieve some outcome, you choose the outcome as your goal, and then control the process used to achieve the outcome. The more effectively you control the process, the more likely you are to hit the desired outcome.... presuming, of course that the chosen process itself is capable of producing the desired outcome.

Choosing outcomes is relatively easy. Choosing effective process is much more difficult. Controlling a process (usually via measurement of some process metrics), once defined, is generally easier than choosing and defining the process.

Jeff Phillips wrote on a related topic back in July. To generalize the problem: how to choose an effective process so you are most likely to achieve the desired outcome?

In software design, one of the more useful concepts to come out in recent years has been design patterns. Can the idea of design patterns be generalized to help choose or design a process? Doing a "web search" (because Google doesn't want googling to become a verb), turns up a link or two. 

IDE Integration tip

I had a tech-support issue come up the other day related to getting IDE integration to work. In sorting through the issue, it turns out that neither QVCS-Pro nor QVCS-Enterprise is very friendly to the non-admin user.... i.e. they both need admin rights to make the necessary registry changes that are required by Microsoft's SCC IDE integration.

Since I'm an admin user on all my machines, it's not a problem I've ever run into. I guess it also goes without saying that neither am I a Windows admin guru. We came up with a successful workaround, and I'll be creating a FAQ on the solution as soon as I can put the pieces together into a coherent presentation.

In the meanwhile, if you are a non-admin user who has given up on getting IDE integration to work, the basic problem can be solved by changing the rights on two hives in the registry.

What you have to do is described nicely by this article (for a product completely unrelated to QVCS or QVCS-Enterprise). Instead of the BSI hive (described in the linked article), you would need to modify the SourceCodeControlProvider hive and the QumaSoftware hive in the same registry tree as described in the article.

New feature poll

I created a new feature poll for QVCS-Enterprise on the forum site.  The idea is to capture some feedback and suggestions so I can prioritize what goes in to the next release of the product. Please stop by and add your two cents.

UPDATE: Add link to forum.

You get what you measure

You get what you measure.

This is an old and faithful management commandment that in my experience is sound advice. As in most things, the devil is in the details.

When I was at UPS  (developing software for their Package Systems division), they had an alphabet soup of different activities that they imposed upon management with the purpose of improving communication between manager and employee. One was called 'Talk-Listen-Act', or TLA. Management was required to schedule 'TLA' meetings with their direct reports. A manager's performance appraisal included measurement of the percentage of their TLA's that they had completed within the review period. Because their TLA 'effectiveness' was closely measured, all the managers within the unit where I worked dutifully scheduled and performed TLA's with their staff.

There may have been some value in having TLA's with some problem members of the staff, but for most, it represented a waste of time for both the manager and the staff member. The best thing that would come of it was perhaps a 'free' (i.e. expensed) lunch for both manager and staff member.

The TLA originated within UPS's operations divisions where the management is white collar and the 'staff' consists of blue collar truck drivers. In that environment, special steps had to be taken in order for management to have any one-on-one face time with their drivers, since the drivers were always out of the office, delivering or picking up packages. In that environment, having some more formal mechanism to encourage communication between management and their direct reports makes sense.

In the environment of software development, where management and staff interact face to face on a daily basis, having the formalism of a TLA was (is?) not a good use of time.... yet, because 'you get what you measure', a lot of cycles were burned to satisfy the metric that its measurement demanded.

In small companies, where the distance between the work you perform and the company's bottom line is short, it's easy to know what you should measure. In large companies, where employees are far removed from the company's bottom line, company management must invent the metrics against which performance can be measured. The choice of metrics is often driven by internal politics, the 'need' to build empires in order to climb the corporate ladder, and/or other motivations that serve their manager advocates more than they serve the business. Because the choices don't obviously flow to the bottom line, it's often difficult to evaluate the utility of the chosen metrics.

In politics, things are similar to the problems faced in large bureaucratic corporations. Instead of playing to the internal audience of corporate players, politicians play to a larger audience. For policy wonks, because their success is measured by the ability to advocate policies that will get adopted vs. the ability to advocate policies that actually work, we witness politicians advocating feel-good programs that have little chance of producing the desired outcome. Because we measure good intentions, good intentions are what we get. It's a wonder that anything works.

You get what you measure -- So it's hugely important (and often very difficult) to measure the right thing.

Swarming behavior

Did you ever notice that cars on the highway seem to travel in packs? This observation hit me when I was southbound on the New Jersey Turnpike. I was a singleton car -- not in a pack, and then was passed by a pack of cars. After the pack passed, I was a singleton again. It was tempting to speed up and join the pack, which is a simple explanation of how car packs form.

I was attentive to this behavior at the time because I had recently read a couple of books on complexity. Complexity theory offers insights into a wide variety of problem domains, the formation of car packs being one of them....

But I spend a lot more time developing software than driving a car. Is there 'pack' behavior in the software development domain? The simple answer is an obvious 'yes'. Whether it's the methodology (e.g. Extreme Programming), the language (e.g. Ruby), the OS (e.g. Vista), etc. we all take shortcuts that put us in one pack or another.

From a business perspective, it's interesting to speculate on what rules must be followed by the pack members in order to create the pack and have it grow. In the flock of birds examples common in the complexity literature, the number of rules that each bird must follow in order to create a flock of birds is quite small.

What rules must prevail when creating a community (a.k.a. pack) to surround a particular methodology, or a particular programming language, or a particular product? Clearly, the one minimal rule is that community membership must confer some perceived benefit to the individual members that compose the community. In nature, we can see the survival value of a pack of wolves, or a herd of elephants. The value of swarming in lemmings is more difficult to understand.

What value is there in swarming/pack/community behavior within the software development domain?

History lesson

In my spare time, I've been working my way through a 4 volume history on the American colonial period and the American revolution. As I write, I'm into the 4th volume, and the revolution is under way.

I know it's cliche, but it's amazing how the patterns of political intrigue have remained constant over these many years. Sure, the names we attach to the good guys' and bads guys' philosophies have changed -- Whig, Tory, Liberal, Conservative, etc., but the patterns in politics are virtually invariant. Politics is a game of power, whether it's played in the boardroom, or in the public square.