My most unpopular idea
Hey there! I'm Nat Bennett, and you're reading Simpler Machines, a weekly letter about making software with other people.
Thought I'd try something a little bit different this week for the header image – usually I use Unsplash if I use something at all, so I can get an image that at least kind of matches the theme. This week instead you're getting one of my photographs, taken recently in San Francisco.
First up I've got a call to action. Friend-of-the-newsletter Elisabeth Hendrickson is launching a course called "The Thinking Leader's Toolkit." If you value this newsletter and you have any interest at all in leading in software organization you should just go sign up for the waitlist right now, I'm serious, you will learn something important and valuable from it.
If you don't already know Elisabeth, she was a VP of Engineering at Pivotal for many years, and led some of Pivotal's most technically and organizationally difficult projects. She's who I go to when I'm facing a hard leadership problem – the kind where I know I'm going to have to choose between "nice" and "kind." She's often able to help me find a course of action that feels right in what started out as a no-win situation.
This particular course is focused on applying systems thinking tools to leadership. From their description:
The problem with leading in even a moderately complex organization is that it can be difficult to reason about cause and effect. There's a significant probability of unintended consequences. The levers, dials, and switches at your disposal interact in ways that are hard to see. Add in the fact that organizations are made of people, and people are not always rational actors. Sometimes it's surprising anything ever moves forward.
The good news is that there are thinking tools that enable you to find the hidden connections between the forces within your organization and find the right leverage points to make changes while minimizing unintended consequences.
So: You will learn tools for understanding what's going on in your organization, and you will learn tools for making changes in your organization. I suspect you will get the most out of this course if you have a clear idea of something you want your organization to do, and you've tried a couple of different ways to get it to do it, but the change you want to make doesn't seem to be taking. There's also a community component, so you'll meet people who share your leadership values.
Anyway, this is all to say, you should sign up for the wait list for this course.
Okay! So! last week I mentioned that I think that XP is basically incompatible with individual performance, but that I'd need to wait until the next issue to get into why I believe that because it requires writing about Christopher Alexander.
Christopher Alexander was an architect and architecture teacher who had a system for designing buildings that shares some important characteristics with Extreme Programming as a system for designing software. If you know about him already you probably know him as the author of A Pattern Language, which is where the software concept of "a design pattern" comes from. He also wrote The Timeless Way of Building, which describes his method of building of which the patterns are a part, and The Nature of Order, which describes the underlying philosophical theory behind the system.
One of the characteristics of his system of building, that it shares with XP, is that his system was capable of routinely delivering projects on-time and under budget, which is otherwise just as rare in construction as it is in software. This is important– we're going to come back to it in a moment.
I've been aware of Christopher Alexander for a long time but his theories recently came to the forefront of my mind because of a book that Richard Fabian has just published about the "failure" of the design patterns movement in software, called Unresolved Forces. In it he describes Alexander's theory of the "two systems" of building buildings – which Alexander calls "System A" and "System B."
You should probably go ahead and read that whole section but I'll quote the key bits that really got stuck in my brain here.
System A is the way of reviewing the lay of the land and the requirements of the people[Battle12]. This was his system. I suppose he called it System A because, in some way, he felt it was the original way.
System B is the money, ego, and image-driven approach—the system of rules and regulations imposed from above without humanity. System B was and is the predominant way we build things in the modern world.
Christopher Alexander made some strange observations during the project. One such observation was the ineffectiveness of System B—not inefficiency, but the inability of the system to produce the best possible outcome given what was available. System B lacks trust and only allows those in charge to know things and make decisions. To maintain control, many feign knowledge rather than be caught out as fallible. This leads to waste and ineffective processes.
There are a lot of differences between System A and System B – more than I can do justice to even in a much longer essay than this one. But I think that the key, core difference is that the goal of System A is a building – the building is an end in itself. The goal of System B is something else – money, power, influence, and above all, credit. System B is incapable of making good buildings, because it doesn't care about good buildings. Making a building is a means to an end, and that end is the self-replication of System B.
Elsewhere in the book Fabian talks about the reception to Alexander's ideas amongst architects – at first positive, and then later extremely negative – and here we get into what I think is the fundamental challenge to "doing Extreme Programming."
Architects had been brought up to believe their trade was all about making an impression, expressing something meaningful with the materials they had. Architecture was an engineering science, but the basis was artistic intent. When Christopher Alexander came along and claimed architecture was a job you should do to satisfy human needs, he implied their whole career was a sham—or conceivably worse, a destructive, wasteful distraction in the world.
System A, basically, takes the architects out of architecture – the architectural ego out of architecture. One of the reasons that it – and Extreme Programming – are so effective at building things that meet human needs is that they are systems for removing credit to individuals from the process of building things.
If you're doing Extreme Programming "right" a lot of you work is going to feel like you're doing "the obvious thing" because when you don't have enough information for the right thing to be obvious, you go out and you get more information. On an XP team, you're much more a conduit of natural truth than you are a grand designer.
People hate this.
For a long time Pivotal didn't have performance evaluation, pretty much at all. When it did get performance evaluation, it was partly because Finance and HR needed it, but it was mostly because Pivots asked for it. They wanted "career growth." They wanted to know what they needed to do to get promoted – to make more money, to have more influence, to have a "larger scope" to work in. They especially wanted the system for these things to be clear – there was a long period where leadership roles were assigned, but they were assigned ad hoc, as needed, which was pretty annoying if you wanted a leadership role but didn't seem to be part of the group those folks were being drawn from.
So here's where we get to what might be my single most unpopular idea:
If you really care about building great software, you need to give up the idea of "career advancement." You especially need to give up the idea of getting "career advancement" from a single company in a neat, well-documented package. There are a lot of reasons for this but the simplest way I can think of to put it is:
Individual credit or great software: Pick one.
Got to wrap this up now and there's lots more to write about – I'm not going to promise to get into it more next week but you will be hearing more about it in the near future.
One last link before we wrap up – Gareth Smith was one of the architects of what was called "cryogenics" at Pivotal, an effort to reduce the cost of maintaining software that was no longer under active development. He wrote up what he knows about the problem online. If you've got a long-running software project you're responsible for you should read this and probably also get in touch with him. He has thoughts, man.
Go make great things, together. - Nat