Stopping Accidental Technical Debt

In one of my earlier posts about technical debt, I differentiated between intentional debt (that taken on deliberately and purposefully) and accidental debt (that which just accrues over time without rhyme or reason or record). Dealing with (in the sense of evaluating, tracking, and resolving it) technical debt is obviously a consideration for someone in an application architect role. While someone in that role absolutely should be aware of the intentional debt, is there a way to be more attuned to the accidental debt as well?

Last summer, I published a post titled “Distance…is the one true enemy…”. The post started with a group of tweets from Gregory Brown talking about the corrosive effects of distance on software development (distance between compile and run, between failure and correction, between development and feedback, etc.). I then extended the concept to management, talking about how distance between sense-maker and decision-maker could negatively affect the quality of the decisions being made.

There’s also a distance that neither Greg nor I covered at the time, design distance. Design distance is the distance between the design and the outcome. Reducing design distance makes it easier to keep a handle on the accidental debt as well as the intentional.

Distance between the architectural decisions and the implementation can introduce technical debt. This distance can come from remote decision-makers, architecture pigeons who swoop in, deposit their “wisdom”, and then fly away home. It can come from failing to communicate the design considerations effectively across the entire team. It can also come from failing to monitor the system as it evolves. The design and the implementation need to be in alignment. Even more so, the design and the implementation need to align with particular problems to be solved/jobs to be done. Otherwise, the result may look like this:

How software applications evolve over time pic.twitter.com/m8vNskoNZ9

— AB (@SamBehnam) April 15, 2017

Distance between development of the system and keeping the system running can introduce technical debt as well. The platform a system runs on is a vital part of the system, as critical as the code it supports. As with the code, the design, implementation, and context all need to be kept in alignment.

Alignment of design, implementation, and context can only be maintained by on-going architectural assessment. Stefan Dreverman’s “Using Philosophy in IT architecture” identified four questions to be asked as part of an assessment:

1. “What is my purpose?”
2. “What am I composed of?”
3. “What’s in my environment?”
4. “What do I communicate?”

These questions are applicable not only to the beginning of a system, but throughout its life-cycle. Failing to re-evaluate the architecture as a whole as the system evolves can lead to inconsistencies as design distance grows. We can get so busy dealing with the present that we create a future of pain:

What if your real problem is this? pic.twitter.com/YHWKDUK3K7

— Steve Whitla (@swhitla) April 19, 2017

At first glance, this approach might seem to be expensive, but rewriting legacy systems is expensive as well (assuming the rewrite would be successful, which is a tenuous assumption). Building applications with a one-and-done mindset is effectively building a legacy system.

Advertisement

Form Follows Function on SPaMCast 438

Once again, I’m making an appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

This week’s episode, number 438, features Tom’s essay on using sizing for software testing, Kim Pries with a Software Sensei column (canned solutions), and a Form Follows Function installment based on my post “Organizations as Systems and Innovation”.

In this episode, Tom and I discuss how systems must fit into their context and ecosystem, otherwise it can be like dropping a high-performance sports car engine into a VW Beetle. Disney-physics may work in the movies, but it’s unlikely to be successful in the real world. If all the parts don’t fit together, friction ensues.

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

Organizations as Systems and Innovation

Over the last year or so, the concept of looking at organizations as systems has been a major theme for me. Enterprises, organizations and their ecosystems (context) are social systems composed of a fractal set of social and software systems. As such, enterprises have an architecture.

Another long-term theme for this site has been my conversation with Greger Wikstrand regarding innovation. This post is the thirty-fifth entry in that series.

So where do these two intersect? And why is there a picture of a Swedish king from four-hundred years ago up there?

Innovation, by its very nature (“…significant positive change”), does not happen in a vacuum. Greger’s last post, “Innovation arenas and outsourcing”, illustrates one aspect of this. Shepherding ideas into innovations is a deliberate activity requiring structural support. Being intentional doesn’t turn bad ideas into innovations, but lack of a system can cause an otherwise good idea to wither on the vine.

Another intersection, the one I’m focusing on here, can be found in the nature of innovation itself. It’s common to think of technological innovation, but innovation can also be found in changes to organizational structure and processes (e.g. Henry Ford and the assembly line). Organization, process, and technology are not only areas for innovation, but when coupled with people, form the primary elements of an enterprise architecture. It should be clear that the more these elements are intentionally coordinated towards a specific goal, the more cohesive the effort should be.

This brings us to Gustavus Adolphus of Sweden. In his twenty years on the throne, he converted Sweden into a major power in Europe. Militarily, he upended the European status quo in a very short time (after intervening in the Thirty Years’ War in 1630, he was killed in battle in 1632) by marshaling organizational, procedural, technological innovations:

The Swedish army stood apart from its’ contemporaries through five characteristics. Its’ soldiers wore uniform and had a nucleus of native Swedes, raised from a surprisingly diplomatic system of conscription, at its’ core. The Swedish regiments were small in comparison to their opponents and were lightly equipped for speed. Each regiment had its’ own light and mobile field artillery guns called ‘leathern guns’ that were easy to handle and could be easily manoeuvred to meet sudden changes on the battlefield. The muskets carried by these soldiers were of a type superior to that in general use and allowed for much faster rates of fire. Swedish cavalry, instead of galloping up to the enemy, discharging their pistols and then turning around and galloping back to reload, ruthlessly charged with close quarter weapons once their initial shot had been expended. By analysing this paradigm it becomes apparent that the army under Gustavus emphasized speed and manoeuvrability above all – this greatly set him apart from his opponents.

Dale James, “THE FATHER OF MODERN WARFARE & THE MILITARY REVOLUTION”, February 24, 2014

By themselves, none of the innovations were original to Gustavus. Combining them together, however, was and European military practice was irrevocably changed. Inflection points can be dependent on multiple technologies catching up with one another (since the future is “…not very evenly distributed”), but in this case the pieces were all in place. The catalyst was someone with the vision to combine them, not random chance.

Emergence will be a factor in any complex system. That being said, the inevitability of those emergent events does not invalidate intentional design and planning. If anything, design and planning is more necessary to deal with the mundane, foreseeable things in order to leave more cognitive capacity to deal with that which can’t be foreseen.

Organizations as Systems – “Uneasy Lies the Head that Wears the Crown”

 

One of the benefits of having a (very) wide range of interests is that every so often a flash of insight gets dropped into my lap. In this case, it was a matter of “We must recognise that single events have multiple causes” showing up as a suggested read from Aeon on the same day that Thomas Power retweeted this:

I firmly agree with @RoryStewartUK that "there is no power anywhere" pic.twitter.com/v0EQbQSaiU

— anomalyuk (@anomalyuk) July 29, 2016

The image in the tweet is an excerpt from an interview with Rory Stewart, Conservative Member of Parliament for Penrith in the UK. The collision of themes between the two articles struck me.

“You get there and you pull the lever, and nothing happens.”

The behavior of a system is determined not by the structure of the components of that system, but by the relationships and interactions between those components. Moreover, those relationships and interactions are dynamic and complex, even when that’s contrary to the designer’s intent. In fact, the gap between the behavior as intended and as experienced introduces a tension. I would argue that it’s less a matter of nothing happening when the “lever” is pulled and more that something different from what’s expected happens. Rather than simple cause and effect, “if this, then that”, multiple factors are in play.

In mechanical systems, parts wear, subtly changing the physics of the mechanism. Foreign objects invading the system can impose change in a more dramatic fashion. Context, both that of the system’s internals and its environment, influences its operation.

As was noted in the Aeon article, agency adds to the complexity. In social systems, all of the “components” are individuals with agency, making those systems chaotic in at least the colloquial sense of the word. Using Tom Graves’ sense-making framework, SCAN, these interactions fall into the more uncertain quadrants, either “Ambiguous but Actionable” or “Not-known, None-of-the-above”. Attempting to deal with them as though they fell into the “Simple and Straightforward” quadrant increases the likelihood of getting unexpected results.

Learning/sense-making is critical to dealing with change, whether internal or external (or both). The manner in which change is appreciated and reacted to, affects the health of the system. Consider three boilers: one where pressure is continuously monitored and adjusted, one which is equipped with a pressure relief valve which will open prior to a catastrophic failure, and one where problems are signaled by an explosion. It’s a trivial exercise to come up with examples of social systems, from businesses all the way up to political systems, using the third method. It’s probably a more interesting exercise to consider why that’s the case for so many.

In a recent post, “Architecting the shadows”, Tom Graves discussed the phenomenon of ad hoc, unofficial “shadow” organizational interactions that arise in order to get work done:

In SCAN terms, we could summarise the generic positioning of all ‘shadow’ functions – shadow-IT, shadow-business-models, shadow-management and more – much as follows:

In other words, the ‘shadow’-world exists to deal with and resolve all the uncertainties and over-simplifications that overly-mechanistic management models tend to overlook. Even in more aware management-models, in which some exploration of the uncertain is officially sanctioned and allowed, the shadow-world will still always need to exist – particularly whenever the work gets closer towards real-time action:

In closing the post, Tom makes the following observation:

As the literal ‘the architecture of the enterprise’, a real enterprise-architecture must, by definition, cover every aspect of the enterprise – including all of the ‘shadow’-elements. And yet, also by definition, those ‘shadow’-elements cannot be brought ‘under control’ – not least because they deal with the themes and factors that are beyond the reach of conventional concepts of ‘control’.

The “conventional concepts of ‘control'”, the deluded belief that complex interactions can be managed as though they were simple, poses an immense risks to organizations. Even attempting to treat those interactions as merely complicated, rather than complex, introduces a gap between reality and perception, between “the way we do things” and the way things actually get done. When the concept and reality of the system’s interactions differ, it’s more likely that the components of the system will wind up working at cross-purposes.

In a comment on Tom’s post, I noted that where the shadow elements are a “French Resistance”, flouting the rules in order to actually get work done, that’s a red flag.

The most important thing to learn about management and governance is knowing when and how to manage or govern and more importantly, when not to. Knowing what can actually be controlled is an important first step.

Skating to Where the Puck Will Be

I skate to where the puck is going to be, not where it has been.

Wayne Gretzky

 

Business people have a thing for sports metaphors, and this one in particular is a favorite. So much so, that Jason Kirby in “Why businesspeople won’t stop using that Gretzky quote” observed:

Its popularity has much to do with the ego of businesspeople who think they’re the Gretzkys of their industry. But, more than that, it appeals, in a way no other sports cliché does, to the current obsession with that other insidious buzzword, innovation. Get ahead of the competition by figuring out what the market will look like five years from now, says the management consultant to the client, while handing him a substantial bill. It’s that simple.

Of course, it’s not. Gretzky’s uncanny ability to read plays has never been matched. The hockey world has yet to produce another player capable of coming close to matching his record. Which makes the adoption of his quote by businesspeople all the more empty and galling. Warren Buffett can get away with it. Maybe Steve Jobs. But that’s it.

Do you have to be a Gretzky, or a Buffett, or a Jobs in order to get it right?

Prediction is very difficult, especially if it’s about the future.

Niels Bohr

 

Nonetheless, difficult is not the same as impossible. Likewise, the future can be a very big target. Hitting the bits far down the road will be much more difficult than those closer in.

Greger Wikstrand and I have been discussing that “insidious buzzword”, innovation, for more than six months now. This post is the 23^rd in the series.

Given the pace of change, “insidious buzzword” seems a bit dismissive. Someone born in 1903 when the Wright brothers first flew what was essentially a motorized kite might just be retiring in 1969 when the Concorde first flew. Almost an entire Radio Shack ad from 25 years ago is now available in the form of a cell phone (for a lot less money as well). Doubtless, some people misuse the term. The phenomenon, however, is very real.

So let’s return to the question of ability to anticipate change. Do you have to be a Gretzky, or a Buffett, or a Jobs in order to get it right? I think that’s a facile opinion, the Great Man theory applied to technology and business.

Greger’s last post, “Inevitable change”, contains part of the reason why I think it’s intellectually lazy to think that innovation is the province of the superstar:

Most changes in evolution are small. They are not big morphological changes. They are small physiological and immunological changes. The ability to resist new disease and the ability to consume new food is much more important than the (seemingly) bigger changes.

In his post, Greger talks about punctuated equilibrium versus phyletic gradualism, sudden radical change versus constant small incremental changes over time. In my opinion, it’s a combination. Species (and organizations) can reach a point where they are no longer fit for the ecosystem they inhabit. They reach that point, however, by degrees.

Likewise, Gretzky skated to where the puck would be, not in one leap, but step by step. Iterative sense-making and decision-making is, in my opinion, far more likely to lead to long-term consistent success than superhuman leaps of intuition. Rather than requiring just the right move at just the right time, what’s needed is awareness and adaptation. Constant, intentional learning is required to ward off the inertia that can be so deadly in an ever-changing environment.

Innovation is a matter of making changes to remain relevant/fit as the environment around you changes. Sometimes those changes may be sudden, but even gradual change can seem sudden to those standing still.

The straw that broke the camel’s back didn’t weigh any more than those that didn’t. It just happened to be one too many. That means there were lots of opportunities to move right up until there weren’t any more.

[Wayne Gretzky photo by Håkan Dahlström via Wikimedia Commons]

Learning to Deal with the Inevitable

 

My last post, “Barriers to Innovation”, began with a question. Is innovation inevitable? By the end of the post, that question had changed. Is innovation inevitable for your organization? Tom Cagley left a comment suggesting another change:

Think about changing the question again. “Is innovation inevitable?” might be better stated as “Is change inevitable?” The answer to the latter question is yes but no to the former. Change and innovation do not have the same thing.

Tom’s comment was, of course, right on the money. Change is inevitable and while all innovation is change, not all change is innovation. Scott Berkun’s definition of innovation is still my favorite:

If you must use the word, here is the best definition: Innovation is significant positive change. It’s a result. It’s an outcome. It’s something you work towards achieving on a project. If you are successful at solving important problems, peers you respect will call your work innovative and you an innovator. Let them choose the word.

Change, however, is not guaranteed to be either significant or positive. It will, however, be. It may be unwanted, it may be denied, but it not will be avoided. Organizations, like organisms, demonstrate their fitness for purpose via adapting to change. Organizations, like organisms, die when their ecosystems change around them and they fail to follow suit. Research in Motion, who quickly went from leader to laggard in the mobile communication space provides a graphic example of this.

Back in March, I noted that I find myself increasingly drawn to exploring the fractal nature of systems, both software and social, and their ecosystems. Understanding the social systems that make up the ecosystem of a software system is, in my opinion, key to getting and keeping the best possible fitness for purpose. Technology cannot help an organization when its structure and processes are working at cross purposes. Chasing these fractals to their logical end, we move from within the bounds of the organization out into its ecosystem. This is the level that Tom Graves refers to as the whole-enterprise, the “bold endeavour”.

This chasing of the fractals to form a mental model of the environment in which you’re operating is also known as situational awareness. Situational awareness is critical to effective sense-making which is critical to effective decision-making. Just as a body of troops with poor situational awareness risks walking into an ambush, an organization with poor situational awareness risks similarly unpleasant surprises (at least figuratively).

To be effective, the sense-making/decision-making process should be a ongoing process. Likewise, it is a process that should span the levels of concern, tactical through strategic, that make up the whole-enterprise architecture. To be effective, the process should yield action, adapting the organization to the changing context, not just insights into the divergence between the organization and its ecosystem. To be effective, you need to be intentional or lucky (and you can only control one of these).

My views regarding this are based on my own experience and what I’ve synthesized over the years from a variety of sources. I was pleased to get some affirmation recently while attending an event where Professor Edward Hess of the University of Virginia’s Darden Graduate School of Business discussed his book, Learn or Die: Using Science to Build a Leading-Edge Learning Organization. His premise was effective learning, something that humans can be really bad at, is key to organizational effectiveness. This view obviously resonates with me (which carries a hint of irony given that he talks about confirmation bias as something that inhibits effective learning – you’ll have to trust me that that’s not the case here).

Because of time constraints, Professor Hess’ talk did not go into the same depth as his book (which I’ve since read and will be referring to in upcoming posts), but some of the key points relevant here were:

• a learning culture is useful regardless of whether the goal is efficiency or innovation
• a learning culture is created intentionally
• candor, facing the “brutal facts” is essential to a learning culture
• permission to fail and psychological safety does not equate to lack of standards/control, a learning culture takes risk tolerance into account

His most important point is that while it is in our nature to be “suboptimal learners” who let ego and fear get in our way, we can learn to be better learners, both individually and as a group. Diversity, by virtue of bringing multiple mental models to the table, can diminish cognitive blindness (Gooch’s Paradox – “things not only have to be seen to be believed, but also believed to be seen”). By understanding that we are not rational thinkers, we can take measures to avoid the pitfalls of fast thinking.

In a changing world, sitting still can be deadly. Motion, however, provides little benefit if it’s not purposeful and intelligent. A cohesive whole-enterprise with a culture of intentional, effective sense-making and decision-making (learning) is well placed to make better moves in a dynamic world.

Barriers to Innovation

 

Is innovation inevitable?

Greger Wikstrand and I have been trading blog posts on innovation since last November. In his latest post, “Credit card fraud and stalled innovation”, Greger discusses the relatively slow pace of innovation in credit card security. Those best placed to increase security neglect it because they don’t own the risk (a concept called “moral hazard”).

Sometimes, a potential innovation is not the best route to take. For example, the situation I discussed in “What’s Innovation Worth”, where change was avoided because the payoff didn’t justify the cost. Sometimes, however, potentially valuable innovation can be blocked in ways similar to what Greger outlined.

Laws and regulations can introduce perverse incentives that distort economic conditions. Ironically, where this hurts some innovations (e.g. Uber and other “gig economy” companies), it can also unintentionally push others. Increases in minimum wage laws are making automation more likely for some jobs.

External factors are far from the only barriers to innovation. Technological innovations, no matter how promising, will fail to flourish when placed in an inhospitable ecosystem. If all the systems, social and technological, fail to complement each other, then effectiveness will be diminished via friction. Technology, organization (structure), and process are all intertwined and interdependent.

Culture and structure are aspects of social systems that can contribute to impeding innovation. Organizations which are highly focused on efficiency and stability will be disposed to avoid the risk inherent in experimenting. Likewise, rigidly siloed organizations will have difficulty with activities that require crossing reporting structures. This can be the result of deliberate and destructive office politics, or less obvious (therefore, more insidious) cognitive biases that lead to evidence being overlooked:

Yet ‘evidence’ literally means ‘that which is seen’. And here we hit right up against a fundamental problem of cognitive-bias, sometimes known as Gooch’s Paradox: that “things not only have to be seen to be believed, but also have to be believed to be seen”.

Tom Graves, “Services and disservices – 3: The echo-chamber”


Inertia, the “indisposition to motion, exertion, or change”, is another social system innovation killer. In the seventh installment of our series on innovation, “Organizations and Innovation – Swim or Die!”, I made the point that organizations need constantly to adapt to their changing contexts or risk “death”. Sitting still in a changing world is a losing tactic.

It should be obvious that all the barriers to innovation I’ve listed are aspects of the social systems involved. The technology part is relatively easy compared to the social. Technology (at least at present) isn’t lazy, complacent, biased, fearful, or malicious. The upside is that organizations, being composed of people, can change.

To return to the question above, is innovation inevitable?

Perhaps. The better question is whether it’s inevitable for your organization. The more your organization is subject to the barriers listed above, the more likely an organization not subject to them will eat your lunch.

The Seductive Myth of Greenfield Development

Greger Wikstrand‘s tweet from earlier this week packed a wealth of inspiration into one image:

Nothing is ever gone... pic.twitter.com/MVi9Ty92iV

— Greger Wikstrand PhD (@GregerWikstrand) December 7, 2015

The second statement particularly resonated with me: “The present is built on the past.”

How often do we, or those around us, long for a chance to do things “from scratch”. The idea being, without the constraints of “legacy” code, we could do things “right”. While it’s a nice idea, it has no basis in reality.

Rewrites, of course, will involve dealing with existing data. I’ve yet to encounter a system where no one was interested in the data when it was replaced. I’ve shut down a few where there was no interest, but that’s a different story. The need for that existing data will serve as a potent influence on what can or cannot be done with the replacement system. Likewise, its structure. It’s not reasonable to assume that the data will be any less “legacy” than the code.

We might be tempted to believe that brand new systems escape this pitfall. In doing so, we fail to consider that new systems still must deal with the wants, needs, and attitudes of their stakeholders. People, processes, and organization form the ecosystem that new systems must fit into as surely as replacement systems must.

A crucial part of problem solving is having an adequate understanding of the problem. Everything has a backstory. Understanding the backstory is dependent on understanding the ecosystem the thing fits into. This what Sullivan was talking about when he said “…form ever follows function”.

Nothing’s Ex Nihilo.

Organizations and Innovation – Swim or Die!

One of the few downsides to being a Great White shark is that they must continually move, even while sleeping, in order to keep water moving over their gills. If they stay still too long, they die. Likewise, organizations must remain in motion, changing and adapting to their ecosystem, or risk dying out as well.

Greger Wikstrand and I have been carrying on a discussion about architecture, innovation, and organizations as systems. Here’s the background so far:

1. “We Deliver Decisions (Who Needs Architects?)” – I discussed how the practice of software architecture involved decision-making. It combines analysis with the need for situational awareness to deal with the emergent factors and avoiding cognitive biases.
2. “Serendipity with Woody Zuill” – Greger pointed me to a short video of him and Woody Zuill discussing serendipity in software development.
3. “Fixing IT – Too Big to Succeed?” – Woody’s comments in the video re: the stifling effects of bureaucracy in IT inspired me to discuss the need for embedded IT to address those effects and to promote better customer-centricity than what’s normal for project-oriented IT shops.
4. “Serendipity and successful innovation” – Greger’s post pointed out that structure is insufficient to promote innovation, organizations must be prepared to recognize and respond to opportunities and that innovation must be able to scale.
5. “Inflection Points and the Ingredients of Innovation” – I expanded on Greger’s post, using WWI as an example of a time where innovation yielded uneven results because effective innovation requires technology, understanding of how to employ it, and an organizational structure that allows it to be used well.
6. “Social innovation and tech go hand-in-hand” – Greger continued with the same theme, the social and technological aspects of innovation.

The over-riding them of the conversation is that innovation doesn’t happen in a vacuum. The software systems that people tend to think about when talking innovation are irrelevant outside of the context of the organizations that use them to innovate. Those organizations are irrelevant outside of the context they operate in, their ecosystem. A great organization with cutting edge technology that has no market is not long for this world. This fractal nature of social systems using software systems within an overarching ecosystem is why I find enterprise architecture increasingly relevant to software architecture. I use “increasingly” as in my awareness of its importance is increasing; the relevance has always been there. Matt Ballantine’s post, “Down Pit”, points this out in the context of Britain’s post-WWII coal mining industry.

Like the sharks, organizations cannot stay immobile and expect to live. Unlike biological organisms, organizations have a far greater degree of control over their internal structures and processes to enable them to adapt to their environment. Whether it’s referred to as Enterprise Architecture or not, there is a need for organizations to understand the context in which they operate. Adapting to this context requires both technological and social (structural and cultural) flexibility.

Unlike the sharks that evolved to “sleep swim”, organizational adaptation must be intentional, considered, and ongoing. Rather than formulaic responses, which tend to jump to the ends of spectra, tailoring is needed to find the right mix. This is one concept that I neglected to fully develop in “Fixing IT – Too Big to Succeed?”, too distributed is likely to be as bad as too centralized. Some aspects of IT need to be centralized to be effective whereas others need to be federated to be effective. Not all embedded teams will be at the same organizational scope. Pragmatism is required as well. Blindly adhering to the rule that each application have a dedicated permanent product team means that the company will either go bankrupt or only units that can afford a team will have applications. A middle ground, while not doctrinally pure, is both possible and preferable.

It’s not enough to just swim, you must swim with purpose. Otherwise, all that emerges is entropy.

Form Follows Function on SPaMCAST 327

It’s time for another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

SPaMCast 327 features Tom on standups, a discussion of my “Who Needs Architects? – Navigating the Fractals” post and an installment of Jo Ann Sweeny’s column, “Explaining Communication”.

Cheers!