“Distance…is the one true enemy…”

Gregory Brown tweeted a great series on the problem of distance last week:

https://twitter.com/jetpack/status/752569280835747844 https://twitter.com/jetpack/status/752574380186726400 https://twitter.com/jetpack/status/752574545689714688 https://twitter.com/jetpack/status/752574748786327552 https://twitter.com/jetpack/status/752574927266541568 https://twitter.com/jetpack/status/752575168468414465 https://twitter.com/jetpack/status/752575481451536384 https://twitter.com/jetpack/status/752576057715359745 https://twitter.com/jetpack/status/752576310048948224

It’s amazing how much information can be conveyed in nine tweets. It’s amazing how many aspects of a very complex socio-technical undertaking, software development, are affected by this concept of distance. I would argue that this concept of distance applies likewise to the social systems that software development belongs to as a component part.

Distance between action and result as well as distance between result and response are just as much a problem for social systems as software systems. This was one of the main themes of “The Ignorance of Management – Deep and Wide”, trying to manage too far down the hierarchy just doesn’t scale. There are too many decisions at too deep a level of detail across too many areas for this to be effective.

It’s a case of mismatched impedance, resulting in overload. Increased distance equals increased transmission time, meaning that remote decisions will either take longer (risking timeliness of the decision) or will have to be made with less consideration (risking the fitness of the decision). Likewise, the greater number of decisions being made due to an inappropriate distance will force the same set of trade-offs. Time spent on lower-level issues also reduces time available for issues that are appropriate to the decision-maker’s level. This places even more pressure on the decision-maker in terms of being either hasty or late.

Ironically, better control is likely to come from delegating decision-making to the appropriate level of the organization than attempting to micro-manage. The true test of leadership, in my opinion, is not how things run when a leader is present, but how things run when they’re not. Adding distance stacks the deck, and not in your favor.

Form Follows Function on SPaMCast 403

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 403, features Tom’s essay on Agile practices at scale, Kim Pries on transformations, and a Form Follows Function installment based on my post “NPM, Tay, and the Need for Design”.

Although the specific controversies have died down since we recorded the segment, the issues remain. Designs that fail to account for foreseeable issues are born vulnerable. Fixing problems after they “emerge” can be much more expensive than a little defensive design.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

When Will We Learn?

We’ve all heard the sayings about history repeating. Did we pay attention? Did we actually hear what was said, or were we just in the room when it was mentioned? Did we learn anything?

Greger Wikstrand and I have been trading posts on innovation for more than seven months. His last post, “Black hat innovation”, touched on the dark side of innovation:

I think the following are good examples of black hat innovation in the digital space: credit card fraud, ransomware and identity theft. There are many other black hat innovations that does not rely on tech such as chain letters, counterfeit money and even weighted dice.

Greger noted “Sometimes, it might seem as if black hat innovation out paces white hat innovation.” Certainly, a black hat innovator faces fewer barriers to innovation. Following rules is less of a consideration when breaking rules. We also have to be aware of the advantage we give them when we fail to learn from the past. None of the abuse cases that Greger mentioned are black swans. They’re merely new ways to commit old crimes. Waiting to react to a foreseeable issue means we start from behind because we failed to learn.

Failure to learn can manifest in a variety of ways. In his post, “Enterprise challenges”, Peter Murchland noted:

All enterprises face challenges (of varying magnitude and complexity). These challenges are either problems to be solved or opportunities to be pursued. One way of considering these challenges is through the following three lenses – those arising due to:

• external change
• internal change
• growth and development

Peter asserts that the health of an enterprise depends on integrating coherent responses to these challenges into its architecture. This is a position shared by Aaron Dignan in “How To Eliminate Organizational Debt”:

Organizational Debt: The interest companies pay when their structure and policies stay fixed and/or accumulate as the world changes.

Let’s unpack that. As time passes, companies create roles, structures, rules, policies, and other norms that become fixed, and often, difficult to change. This is by design. For example, a company’s travel budget may balloon one year, only to be restricted by a travel policy the next — a well intentioned control designed to reduce expense. If that policy starts costing more than it’s saving (e.g. by reducing commercial success due to a lack of face time, frustrating top talent, etc.), it becomes an unacknowledged debt. The “interest” comes in the form of reduced speed, capacity, engagement, flexibility, and innovation that ultimately undermine the macro objectives of the firm: to survive, thrive, and achieve its purpose.

In other words, failure to learn leads to failure to adapt to a changing context, internal and/or external. This mismatch between the enterprise and its context represents a destructive friction. Since an enterprise is a social system and the components of a social system are people, this means that the effects of this friction erodes morale. Disengaged, demotivated employees will hinder an organization’s ability to deliver effectively. The only question is how much of a hindrance it will be.

In my post “Learning to Deal with the Inevitable”, I talked about the value of a learning culture for an organization. Effective execution requires effective decision-making, which requires learning. If we haven’t learned from the past, then there’s no rational basis for our future actions. We’re winging it solely on the basis of hope.

An organization is unlikely to develop a learning culture by accident. Just as a tornado hitting an auto parts store is unlikely to spit out a sports car, it’s unlikely that a system of sensing and adjusting to an ever-changing environment will emerge without intentional action. The social system that is the enterprise has a design and requires design, much the way an automated system has a design and requires design. Part of that design should incorporate learning.

Different organizations will have different needs and different styles of learning. Getting groups of people together to play with technology (as described by Matt Ballantine in his post “The Art of Play”) may not work for every organization. However, it is shortsighted to make no provision for learning whatsoever. Even the British Army in World War I, a conservative institution with an aristocratic officer corps in a conflict that can be described as 19th century warfare with 20th century weapons, “…developed a number of different methods to disseminate knowledge, catering for a variety of different circumstances and needs”. With a hundred years’ worth of extra experience and technology, it would be hard to justify taking a less rigorous approach.

Building a Legacy

 

Over the last few weeks, I’ve run across a flurry of articles dealing with the issue of legacy systems used by the U.S. government.

An Associated Press story on the findings from the Government Accountability Office (GAO) issued in May reported that roughly three-fourths of the $80 billion IT budget was used to maintain legacy systems, some more than fifty years old and without an end of life date in sight. An article on CIO.com about the same GAO report detailed seven of the oldest systems. Two were over 56 years old, two 53, one 51, one 35, and one 31. Four of the seven have plans to be replaced, but the two oldest have no replacement yet planned.

Cost was not the only issue, reliability is a problem as well. An article on Timeline.com noted:

Then there’s the fact that, up until 2010, the Secret Service’s computer systems were only operational about 60% of the time, thanks to a highly outdated 1980s mainframe. When Senator Joe Lieberman spoke out on the issue back in 2010, he claimed that, in comparison, “industry and government standards are around 98 percent generally.” It’s alright though, protecting the president and vice president is a job that’s really only important about 60 percent of the time, right?

It would be easy to write this off as just another example of public-sector inefficiency, but you can find these same issues in the private sector as well. Inertia can, and does, affect systems belonging to government agencies and business alike. Even a perfectly designed implemented system (we’ve all got those, right?) is subject to platform rot if ignored. Ironically, our organizations seem designed to do just that by being project-centric.

In philosophy, there’s a paradox called the Ship of Theseus, that explores the question of identity. The question arises, if we maintain something by replacing its constituent parts, does it remain the same thing? While many hours could be spent debating this, to those whose opinion should matter most, those who use the system, the answer is yes. To them, the identity of the system is bound up in what they do with it, such that it ceases to be the same thing, not when we maintain it but when its function is degraded through neglect.

Common practice, however, separates ownership and interest. Those with the greatest interest in the system typically will not own the budget for work on it. Those owning the budget, will typically be biased towards projects which add value, not maintenance work that represents cost.

Speaking of cost, is 75% of the budget an unreasonable amount for maintenance? How well are the systems meeting the needs of their users? Is quality increasing, decreasing, or holding steady? Was more money spent because of deferred maintenance than would have been spent with earlier intervention? How much business risk is involved? Without this context, it’s extremely difficult to say. It’s understandable that someone outside an organization might lack this information, but even within it, would a centralized IT group have access to it all? Is the context as meaningful at a higher, central level as it is “at the pointy end of the spear”?

Maintaining systems bit by bit, replacing them gradually over time, is likely to be more successful and less expensive, than letting them rot and then having a big-bang re-write. In my opinion, having an effective architecture for the enterprise’s IT systems is dependent on having an effective architecture for the enterprise itself. If the various systems (social and software) are not operating in conjunction, drift and inertia will take care of building your legacy (system).

[Greek Trireme image from Deutsches Museum, Munich, Germany via Wikimedia Commons]