Archive for April, 2018

Two types of chronic anxiety from “A Failure of Nerve”

I just finished reading A Failure of Nerve: Leadership in the Age of the Quick Fix, by Edwin Friedman. It’s a book about leadership in the #2018TechReadingChallenge.

Friedman’s key concept in the book is chronic anxiety, which is the foremost challenge to leaders. Leaders have “a failure of nerve” when the fail to rise above the anxiety that surrounds them.

Since we all are surrounded by anxiety, we all have the opportunity to become leaders. One of Friedman’s catch phrases is “from parents to presidents,” reflecting that anyone can be a leader, whether you are a leader of a family, or of an entire country. In my day job, I’m a leader by being a senior software engineer, since I am responsible for delivering value, minimizing risk, as well as mentoring the junior developers on the team.

The desire for a quick fix is the first example of anxiety. It occurs when we reactively look to solve a symptom, rather than being thoughtful and addressing the underlying problem. We look for techniques and methods, without realizing that the last 6 methods we tried did not solve the problem. Maybe the quick fix is converting the entire organization to scrum, without realizing that the underlying relationships of your organization are toxic.

A leader is a person who realizes that methods and techniques won’t solve problems. Instead, it’s more about what you do after you make the decision.

Reactivity is the second example of anxiety. Reactivity in leadership is the person who blames others when there is a problem, or who has the same knee-jerk reaction every time. It’s the person who blows up when something unexpected happens. It’s me, when I take it out on a coworker whose work didn’t meet my expectations.

The well-differentiated leader is less reactive. “Those who are less reactive are more self-contained, less blaming, more imaginative, less anxious, and more responsible. When they do seek help, they generally can hear suggestions well, offer less resistance to suggestions for change, and treat their consultant as a coach rather than a savior. Such an approach emphasizes strength rather than weakness, accountability rather than blame, taking responsibility for self rather than feeling for others.” (p. 164)

In a software development context, the well-differentiated leader is the person who is able to maintain their professionalism in the mist of an emergency bug fix. Or the person who is able to clarify expectations and help the team deliver, even when the priorities of the organization seem to be constantly changing. Or a person who handles interruptions to their work with grace, even when it is the 3rd interruption that day.

Anxiety is not just an individual challenge, it is a challenge for organizations and societies at large. Anxiety is a driving force in the emotional processes that permeate our interactions one another. Unchecked, these emotional processes will stifle our imagination. Regardless of the emotions themselves, these processes have a way of being passed down from generation to generation, and so the greatest challenge of a leader is to see and overcome the processes surrounding him or her.

Instead of our imagination being stifled, we must take responsibility for our own being and destiny, which Friedman calls being a well-differentiated leader. This is not a matter of finding the right techniques or having a self-improvement checklist, and so in this sense, the book is not a typical self-help book. Rather, it aligns more with leadership books such as Ordering Your Private World, and Leading with a Limp. It also reminded me of The 7 Habits of Highly Effective People, which I did a review of a few years ago (part 1) (part 2).

What is software architecture?

In my post about Event sourcing and CQRS, I touched on software architecture, but assumed it was already defined. I’d like to dive into that a bit more based on some recent reading.

My definition of software architecture is providing structure that allows productive, effective software development to occur.

Provides structure means having the appropriate technology, practices, culture, and organization in place to allow flourishing. As a software developer I tend to think of the technology (the code) first, but it is certainly not the only thing needed to have effective software architecture. More on that later.

Productive, effective software development means producing software that meets the needs of the business. There are 2 ways that software meets the needs of the business:

  • What the software does
  • How it does it

Or to use more formal terminology:

  • Functional requirements
  • Non-functional requirements

The functional requirements are the business behaviors that provide value to the customer. So for example, if we are creating software for a library, we need the ability to check out books, check in books, and keep a library catalog. Each of these has several behaviors behind it, and there are probably other behaviors I am missing.

The non-functional requirements are also known as the “-ilities” that describe things about the software besides its function. For example, testability is how easy the software is to test. Maintainability is how easy the software is to maintain. There are many others:

  • Evolvability
  • Scalability
  • Security
  • Extensibility
  • Feasibility
  • Reliability
  • Deployability

Besides the above, non-functional requirements might relate to the skill level of developers required to maintain the system, or the structure of the development teams that maintain it. (e.g. the presence of an off-shore development team)

The central claim of software architecture is that you can implement functional requirements in any architecture, but different architectural styles have different non-functional characteristics. What do I mean by that? They provide software structures that emphasize some characteristics at the expense of others. This is a classic engineering trade-off. The job of the software architect is to select an appropriate software structure that matches the non-functional requirements, which should also match the business expectations.

My term “software structure” would overlap with the term architectural pattern, which I first heard about from Mark Richards. Some examples of architectural patterns include:

  • Layered architecture
  • Microkernel architecture
  • Pipes and filters architecture
  • Service oriented architecture
  • Event driven architecture
  • Space-based architecture
  • Microservices

Ah yes, microservices, the buzzword of the last few years. I don’t have time to go into microservices in this blog post, but check out Jimmy Bogard’s Microservices FAQ for more info.

I mentioned earlier that there are different aspects of providing structure. In addition to architectural patterns, which affect the code (technology), there are:

  • organizational patterns (e.g. are teams organized by business capability or by similar job roles? What is the mapping between products to teams?)
  • practices (such as TDD or Extreme programming)
  • culture (probably another blog post altogether)

Ideally all four aspects of structure work together to accomplish the desired outcome. (I’m not sure of the origin of this list of 4 items came from, if anybody knows, leave a note in the comments.)