Pride, Prejudice, and Professionalism in the Business of IT

interior of a 1958 Plymouth Savoy

Twenty-plus years in IT have led me to believe that there are very few absolutes when it comes to software systems. Two that do seem to hold true are these:

  1. Creating systems is esteemed far more highly than maintaining systems.
  2. Systems that are not maintained, will decay.

There are a variety of reasons for this situation, many of which are baked into the architecture of the enterprise. Regardless of the why, however, the two facts remain. Without a response to those issues, entropy is inevitable.

Over the past few days, I’ve seen several blog posts by two different authors dealing with this situation in two different ways:

Jason complains about the non-technical “leadership class” in his first post:

And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.

Again, this is fine, if they leave the technical decisions to the technical experts. And that’s where it all falls down, of course. They don’t.

The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.

This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn’t know that they don’t know.

In his second post he follows up with how to respond:

My pithy – but entirely serious – advice in that situation is Do It AnywayTM.

There are, of course, obligations implied when we Do It AnywayTM. What we’re doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y’know. Like professionals.

I disagree. Strenuously.

If you go to the doctor and they tells you that you will need surgery at some point for some condition, would you expect to be forcibly admitted and operated on immediately?

If you were charged with a crime, would you expect your attorney to accept a plea bargain on your behalf without consultation or prior permission?

If neither of those professionals would usurp the right of their client/patient to make their own informed decision, why should we? Both of those examples would be considered malpractice and the first would be criminal assault in addition. Therefore, I disagree that acting on someone’s behalf without their knowledge or consent is a viable option.

John’s approach, rejecting helplessness and confronting the issues by communicating the costs (with justifications/evidence) is, in my opinion, the truly professional approach. We have a responsibility to make the problem visible and continue making it visible. We also have a responsibility to operate within the limits we’re given. We know far more about our area than someone higher up the management chain, but, that does not equate to knowing more in general than those higher up the management chain. Ignorance is relative. Micro-managing, getting deeper in the weeds than you need to is ineffective. If, however, you’re in the weeds, do you have the information necessary to say that the issue being “interfered with” is one without higher-level consequences? Dunning-Kruger can cut a wide swathe. Trust needs to cut both ways.

Imagine riding as a passenger in a car. You see the car drifting closer and closer to the shoulder. Do you point it out to the driver or do you just grab the wheel? You might prevent an accident or you just might cause one by steering into a vehicle coming up from behind that you didn’t see from your vantage point.

[Plymouth Savoy photo by Christopher Ziemnowicz via Wikimedia Commons]

Disruptive Decency

Well, this turned out to be very much a different post than what I’d first thought.

Last Thursday, CIO published an article titled “Your Pebble smartwatch will live on when Pebble’s servers shut down” that had good news for owners of the Pebble smartwatch:

But now that Pebble has been acquired by Fitbit and is presumably nearing the end of its life, Pebble users fretted that their watches would cease to work once Pebble dies. That’s not the case.

Pebble just rolled out an iOS and Android update that frees its watches from cloud-based online servers. That means when Pebble goes offline, your watch will still work.

Coincidentally, this was one year to the day since I posted “Google’s Parent Company is Stirring Up a Hornet’s Nest”, which talked about Nest’s decision to brick the Revolv home automation hub rather than continue to support them. Fitbit’s decision was a refreshing departure from the attitude demonstrated by Nest (and lampooned by xkcd above). The punchline was going to be: basic human decency seems to be a disruptive tactic these days.

And then I launched Twitter Monday morning:

By this point, I would assume Sunday night’s, incident needs no explanation on my part. Details are still coming out, but regardless of what develops, United Airlines is the loser in this scenario. There’s an old saying is that there’s no such thing as bad publicity.

The old saying is wrong:

The tweet above has plenty of company in the twitterverse, none of it flattering to United or beneficial to its share price. Tweets like this haven’t helped:

The perception that sticks is that an older man, a doctor, was violently removed from a plane in order to allow United to get four of its flight crew to Louisville and United’s CEO is upset about having to “…re-accommodate these customers” (not exactly what’s said, but certainly what will be taken away from that garbled message). Additionally, the poor job done on that earlier message completely undercuts the perceived sincerity of the latter one:

Given United’s past problems with customer service, one might expect more effort would have been spent to prevent incidents like this and they would have been better prepared for dealing with the aftermath of something that did go badly.

Wrong on both counts.

An excerpt from a recent interview of Oscar Munoz (United’s CEO) on Business Insider makes the situation all the more egregious:

Here, in Chicago, it’s miserable because if you don’t leave by a certain time, you are just dead. “I’m going to get there and there are going to be a billion people and the damn TSA line.” By the time you get to sit on one of our seats you are just pissed at the world.

So how do we make all of that a little bit easier? This is the thing. You’ve got that broad issue of anger and anti-industry noise. We’ve lost the trust and respect of the broader public, and so every action we take, they don’t particularly like, they see it negatively. We have to work on that broad communication. I am going to do it at this airline and allow myself to differentiate in the flight-friendly mode so that people don’t immediately have that visceral reaction.

Dragging people off a flight (literally) probably doesn’t fit into the mold of a “flight-friendly mode”.

So I will return to my original punch line: basic human decency seems to be a disruptive tactic these days.

Pragmatic Application Architecture

I saw a tweet on Friday about a SlideShare deck that looked interesting, so I bookmarked it to read later. As I was reading it this morning, I found myself agreeing with the points being made. When I got to the next to the last slide, I found myself (or at least, this blog) listed alongside some very distinguished company under “Reading Material”.

Thanks, Bart Blommaerts and nice job!

Designing Communication, Communicating Design

The Simplest metamodel in the world ever!

We work in a communications industry.

We create and maintain systems to move information around in order to get things done. That information moves between people and systems in combinations and configurations too numerous to count. In spite of that, we don’t do that great a job of communicating what should be, for us, extremely important information. We tend to be really bad at communicating the architecture of our systems – structure, behavior, and most importantly, the reasons for the decisions made. It’s bad enough when we fail to adequately communicate that information to others, it’s really bad when we fail to communicate it to ourselves. I know I’ve let myself down more than once (“What was I thinking here?!”).

Over the past few days, I’ve been privileged to follow (and even contribute a bit to) a set of conversations on Twitter. Grady Booch, Ivar Jacobson, Ruth Malan, Simon Brown, and others have been discussing the need for architectural awareness and the state of communicating architecture.

This exchange between Simon, Chris Carroll and Eoin Woods sums it up well:

First and foremost, an understanding of what the role of a software architect is and why it’s important is needed. Any organization where the role is seen as either just a senior developer or (heaven help us!) some sort of Taylorist “thinker” who designs everything for the “worker bee” coders to implement, is almost guaranteed to be challenged in terms of application architecture. Resting on that foundation of shifting sand, the organization’s enterprise IT architecture (EITA) is likewise almost guaranteed to be challenged barring a remarkable series of “happy accidents”. The role (not necessarily position) of software architect is required, because software architecture is a distinct set of concerns that can either be addressed intentionally or left to emerge haphazardly out of the construction of the system.

Before we can communicate the architecture of a system, it’s necessary to understand what that is. In “Software Architecture: Central Concerns, Key Decisions”, Ruth Malan and Dana Bredemeyer defined it as high impact, systemic decisions involving (at a minimum):

  • system priority setting
  • system decomposition and composition
  • system properties, especially cross-cutting concerns
  • system fit to context
  • system integrity

I don’t think it’s possible to over-emphasize the use of “system” and “systemic” in the preceding paragraphs. That being said, it’s important to understand that architectural concerns do not exist in a void. There is a cyclic relationship between the architectural concerns of a system and the system’s code. The architectural concerns guide the implementation, while the implementation defines the current state of the architecture and constrains the evolution of future state of the architecture. Code is a necessary, but insufficient source of architectural knowledge – it’s not enough. As Ruth Malan noted in the Visual Design portion (part II) of her presentation at the Software Architect Conference in London a year ago:

Slide from Ruth Malan's presentation on Visual Design

While the code serves as a foundation of the system, it’s also important to realize that the system exists within a larger context. There is a fractal set of systems within systems within ecosystems. Ruth illustrated this in the Intention and Reflection portion (part III) of the presentation reference above:

Slide from Ruth Malan's presentation on Intention and Reflection

[Note: Take the time to view the entirety of the Intention and Reflection presentation. It’s an excellent overview of how to design the architecture of a system.]

The fractal nature of systems within systems within ecosystems is illustrated by the image at the top of the post (h/t to Ric Phillips for the reblog of it). Richard Sage‘s humorous (though only partly, I’m sure) suggestion of it as a meta-model goes a long way towards portraying the problem of a language to communicate architecture.

Not only are we dealing with a nested set of “things”, but the understanding of those things differ according to the stakeholder. For example, while the business owner might see a “web site” as one monolithic thing, the architect might see an application made up of code components depending on other applications and services running on a collection of servers. Maintaining a coherent, normalized object model of the system yet being able to present it in multiple ways (some of which might be difficult to relate) is not a trivial exercise.

Lower-level aspects of design lend themselves to automated solutions, which can increase reliability of the model by avoiding “documentation rot”. An interesting (in my opinion) aspect that can also be automated is the evolution of code over time. What can’t be parsed from the code, however, is intention and reasoning.

Another barrier to communication is the need to be both expressive and flexible (also well illustrated by Richard’s meta-model) while also being simple enough to use. UML works well on the former, but (rightly or wrongly) is perceived to fail on the latter. Simon Brown’s C4 model aims to achieve a better balance in that aspect.

At present, I don’t think we have one tool that does it all. I suspect that even with a suite of tools, that narrative documents will still be way some aspects are captured and communicated. Having a centralized store for the non-code bits (with a way to relate them back to the code) would be a great thing.

All in all, it is encouraging to see people talking about the need for architectural design and the need to communicate the aspects of that design.

Leadership Anti-Patterns – The Great Pretender

Roman Mosaic with Tragedy & Comedy Masks as gargoyles above a water basin

My previous leadership type, the Growler, was hard to classify as it had aspects of both pattern and anti-pattern. The Great Pretender, however, is much easier to label. It’s clearly an anti-pattern.

Before entering the working world full-time, I worked in the retail grocery business (both of my parents also had considerable industry experience, both retail and wholesale). I ran into this type more than once. The type is distinguished by a lack of domain knowledge and/or experience, coupled with an apparent inability to trust anyone with knowledge and/or experience. Consequently, the default method of decision-making appeared to be “whatever someone suggests, do something different”. It was as if someone had mixed impostor syndrome and the Dunning-Kruger effect together and skimmed off the most detrimental parts of each.

I remember one July Fourth holiday where a Great Pretender tripled the order for sliced-bread and cut the order for hamburger and hotdog rolls in half. This was based on reading something that said Americans were eating healthier. Unfortunately, that message wasn’t communicated to the Americans in our community (bear in mind, this was many years ago and July Fourth) and we wound up with customers unhappy that we had run out of what they wanted to buy and a lot of soon-to-expire bread that had to be marked down drastically so that it sold before going out of date. The failure to trust subordinates with the right expertise carries costs.

Another Great Pretender questioned his stock crew when he found them taking a break while a truckload of merchandise remained in the back room. The response, “Do you know how long it takes to get all that put on the shelf?” sent him scurrying away. The crew, who were malingering, had a good laugh.

The combination of lack of knowledge and lack of trust opens the door to an interesting manipulation strategy. When you want something from a Great Pretender, you never ask for it directly. It’s always “Boss, should I do this incredibly inane thing that no one in their right mind would do or should I do what I actually want to do?” The response from the Great Pretender is always “Do that second thing” (every single time). I leave it to you, dear Reader, to only use this knowledge for good, not evil.

The idea that someone in a leadership position should be the best at all they oversee is a pretty common one. More than once I’ve seen people claim that the have no respect for a leader that can’t do their job better than them. This attitude, however, fundamentally misunderstands the nature of leadership (hint, effective leadership is more about coordinating the team than doing any one job on the team). This attitude also demonstrates a lack of understanding of the cognitive capacity that would be required to lead a team involved in a minimally complicated undertaking (hint, effective leadership is more about coordinating the team than doing any one job on the team). This attitude also ignores the fact that a leader is responsible for tasks unique to their position (hint, effective leadership is more about coordinating the team than doing any one job on the team). When a team member has this attitude, it can be a problem.

When the leader buys into this attitude, we get the Great Pretender.

Leaders have their own roles and responsibilities to fulfill. This involves dealing with what’s appropriate to their role and relying on others for what’s appropriate to theirs. This requires communication and collaboration. Micro-managing and insecurity are counter-productive. The best leaders, in my opinion, are those that can recognize talent in others and gather around themselves a team of people with complementary strengths. They’re not the experts, but expert at helping a collection of experts come together for a common purpose. That involves placing trust in those being led.

Having to know it all can be fatal.

“Distance…is the one true enemy…”

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

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 399

SPaMCAST logo

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast, number 399, features Tom’s essay “Storytelling: Developing The Big Picture for Agile Efforts”, Kim Pries on deliberate practice, and a Form Follows Function installment on customer-centricity for IT.

Tom and I discuss my post “A Meaningful Manifesto for IT”. It seems obvious that the business of IT is meeting needs, but how many organizations are really happy with what they’re getting? The prevalence of “shadow IT” would seem to indicate that there’s some real discontent.

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