Change

Mankind craves stasis. We want a world that stays put.

There’s just one problem: It doesn’t exist. Even in fiction, creating stasis usually involves stopping time itself.

Change is so intrinsic to our existence that suspension of disbelief is easier for stopping time than it is for eliminating change.

Around the turn of the century, coaches would often use this question:

If you had to choose between writing new code and integrating what you wrote with existing code, what would be your preference?

Usually the goal was to help the person being asked realize that they needed to do something now in order to make integrating new functionality easier later.

Nowadays, I don’t ask that question. I’m not sure if others do, but I definitely don’t.

Ask yourself this question instead: How much time do you actually spend “writing new software” or “writing a new function”?

For me, it’s virtually nil. Almost all my time is spent changing something that I’ve already created. The vast majority of that is spent changing something I’ve already changed a few times before, too.

I bet, for you, it’s probably about the same. Maybe you spend some of your time making shiny new things and then some of it integrating those new things into existing code, but I bet you still spend more of your time on the integration than on the creation.

If not, this might not be the right book for you. Also, in that case, please reach out to me and tell me how I can get into the mystical Garden where you probably reside.

As I said, despite the fact that it’s an impossibility, people crave stasis.

The very idea of a “software project” is based on the notion of a sort of “plastic stasis”: Things are the way they are until we change them and then they are—and will stay—the new way.

The goal of “software project management” was to treat software like something that was built… the same as a bridge or a building.

Yet pursuit of this goal led to repeated and massive failure.

So people started to wonder why making software wasn’t working.

One factor that was identified was “requirements uncertainty”.

“It’s impossible to know everything you need,” they’d say, “because software is so abstract.” Or, sometimes, “…because software is too complex.”

This is tantamount to saying “People can’t come up with big plans and make them happen.”

Yet as I write this, I am sitting in my home in a master planned community. I push data to my git repo on a route that sometimes includes a satellite, which was lifted into space by a rocket.

People devise and execute complex plans all the time. The result is, quite literally, history.

Try this thought experiment.

Imagine the best product manager you’ve ever known. Heck… imagine the best product manager of whom you can even conceive.

To me, this product manager has a superlative ability to decide what is “in” and what is “out”. He does a good job of making decisions about what really deserves to be in a product and what doesn’t.

Now let’s imagine a product. Maybe a drone courier service to connect businesses within local regions.

Can he make good, solid “in vs. out” decisions on scope?

My business partner, Luniel de Beer certainly would be able to do this. He could scope it out and have all the behaviors defined correctly to within 99.5% accuracy before development began.

A team could then consume a list of .feature files and just start making the software until they had implemented the solution.

There are other good reasons to not do things this way, but I know he can.

So I don’t think “requirements uncertainty” or “complexity” is really the issue.

Now let’s extend our thought experiment:

A competitor beat us to the punch and captured the Los Angeles market. It looks like they’re going to be able to roll out to other major cities before us, too.

We were expecting to be able to sell into a large, dense environment with a relatively temperate climate. Now, we’re faced with an uphill battle wherever we turn because they’re going to have brand recognition even if we start serving a city they don’t serve when our platform is ready.

To keep our venture afloat, we need to do something radical and the C Suite has decided to pivot from dense populations with mild climates to sparse populations with periods of hostile weather conditions. We’ll make robust drones that travel over land and keep people connected even when they have high winds or are snowed in.

A “perfect plan” for the original goal is still a “perfect plan” for that goal, but it’s no longer suited to the new goal.

This brings me back to the idea of “requirements uncertainty”.

It’s not that people couldn’t predict the requirements for what they wanted to build. Really, it’s that people can’t actually predict what they want to build.

If we could know—truly know—what would be needed in the future, we could easily plan out building it. We might still choose an Agile work-management strategy, but it wouldn’t be a result of supposedly “not being able to plan ahead”.

What people call “requirements uncertainty” is really just the uncertainty innate in our universe… Changing goals, shifting markets, emergent technologies, fluctuating conditions, and more all conspire to create choppy conditions for software development (or maybe even for product development in general).

Change is an external influence we can’t control.

So, as a result, we spend most of our time as coders changing what we already made. It’s okay. It turns out it works better in a lot of ways than the other would, if it were even possible.

…but make no mistake: The reason we take an Agile approach is that the other approach simply does not work. An iterative and incremental way of managing work does.

All other benefits are ancillary.

There are things that we make and let stand the test of time. Books are one example. For centuries, a book was written and released as is. Small changes were handled with errata sheets. Major revisions became new editions, which were effectively treated as books.

Bridges are another example. Sometimes new access points are added and maintenance is definitely needed to keep them from collapsing, but basically you build a bridge and there it is.

These are things that are “built” - we make them and then they are the way they are.

Books are not built with change in mind because, generally, no need to change them. Bridges are the same.

A book is at once timely and timeless. When you read The Space Trilogy by C.S. Lewis, you don’t think “Well that’s not how it is!” at his description of the surface of other planets. At most, you think “Oh. Right. They didn’t have the data on that, yet.”

A bridge is there to help people cross some kind of obstacle and such obstacles seldom change. In the case of a river that might meander, efforts are made to control or absorb that change by either forcefully channeling the river along a certain path or putting the entry and exit both out of the range of the river’s wandering.

When we build something, we build it to stand the test of time because it is solving a problem or addressing a need that basically does not shift or evolve.

Now I’d like to look at coding by comparison.

Programming languages quickly evolved to have rigid structure - something that you can easily, predictably, and repeatably attach behavior and descriptions.

An emphasis is often placed on “understanding” code. Many people claim one of the primary aspects of good structure is that it allows you to understand code.

Indeed it does…but why is it that you would need to understand code?

It’s always to change it. Either to change the existing code into something else or to write a replacement for the existing code. Both are changes to the system in which a piece of software lives.

Change is the primary force driving all things in software development.

So I believe it should be the main factor to which we attend.

I’m far from alone. There have been many attempts to address change as a force.

In the early days, as we just saw, people devised programming languages themselves as a way of making software easier to change.

After that came a number of other innovations. To name a few:

• Object-Oriented Programming
• Design Patterns
• DRY and SOLID principles
• Test-Driven Development
• Domain Driven Design

Software developers have been building tooling and methodologies to support change since practically the beginning of software. We’ve been doing it since long before the business and process people caught up and realized they needed to actually manage change.

…but there’s been something missing the whole time.