People are the most important part of any organization. Most businesses recognize this. They attempt to motivate their employees and create enriching work experiences. This emphasis is important but, as is often the case, when you focus strongly on one thing, there’s a chance that you miss another.

 

What would happen if we decided to consider code - the technical systems of our organization - as important as people? What if we saw code as an equal player - something that needs to be in our awareness if we want to keep organizations vital?

 

We might do some things differently..

 

 

Surfacing

 

Many organizations have little to no awareness of the health of their software. They might see the big picture. They might know what systems should be rewritten or replaced in the next five years, but they don’t know the particulars. They don’t know what’s easy or hard to change, or how code will react to their plans.

 

They see software as a collection of features. It’s easy to forget that code is physical. It has its own qualities. We can rate every piece of code on health and ease of change. That information can be extremely useful in planning. Tradeoffs become visible. You can see how each idea that anyone has about how to move forward interacts with short term and long term cost.

 

Think about the most intractable system in your company. At every stage of its life it was either easy or hard to change. At some point it tipped. Maybe one of its pieces tipped first. How many people saw it coming? Did the organization learn from its history? Did it see the effects of choosing one feature rather than another at a particular time? Of not making conscious decisions based upon readiness? This is code impact.

 

Let’s turn it around. Does the organization know how the difficulty of that code is affecting people? Each new feature? The ability to respond in the market?

 

Surfacing is the process of creating deep awareness of these interactions. Awareness has to be based on information. We can grade areas of our systems and see how they change over time. We can have continual conversations about the quality and readiness of our systems not just at the development level, but at the organization level. We can feed that information into our work and make better choices.

 

 

Planning

 

Organizations that do software development have a number of different ways of planning their work. In a product company there is typically a product roadmap or a portfolio of features that are organized in backlogs. Planning involves shuffling their priorities and making sure that you have enough market understanding to figure out what that work should be. 

 

What’s missing here? The thing that is missing is a view of what the organization has - the software that it has created. If we assess it, we may be able to see easy things that we can do to provide value to our customers. Often these insights are technical. When we understand a system thoroughly we can see tweaks that can create additional value that we night miss otherwise.

 

This is a complete inversion isn’t it? It’s the opposite of customer-centric strategic thinking, but it’s a step toward gaining information we can use to augment our strategies. Business needs this view of what is easy and what is hard. This is a richer communications channel than seeking and receiving estimates.

 

Software systems grow like trees. If you look at any piece of wood you see  that it has a grain - a natural direction for growth. The work we’ve already done in code facilitates ease in certain directions. When we think of features that don’t fit the grain, we can create new systems or new areas of code rather than shoe-horning features into current ones. When we place what we have on an equal footing with that we want, we have different and often better options long term. 

 

Organizations that are aware of their code can adjust particular features, delay them or even imagine higher value ones that may be more durable in the long run.

 

 

Reacting

 

Code adjusts to us and we adjust to code. Code tends to mirror our team structure, and we create structures to deal with the effects of code - we create customer support, quality assurance and maintenance organizations. If code and organization interact at this deep level, the way we form teams and the way we work are vitally important.

 

When we ask what the code needs, we arrive at the insight that it needs different expertise at different times. The best person for a particular effort might be in a different part of the organization. The code may need them to change teams temporarily to make key contributions, lend their experience and grow other people. Organizations that are aware of these skill sets and what their code needs can create rotation policies and make strategic plans to grow their people and their systems in tandem. 

 

To do this, organizations need to become much more comfortable with changing team structure. There’s a belief in that software development that gelling a team is hard. When we have a gelled team, we do whatever we can to keep it intact and functioning well. The problem with this approach is that it assumes that teaming and re-teaming can’t be easier. It can. It’s a learnable skill.

 

Since code reacts to us, we have to be adaptable enough to take the lead in the dance between code and and team.

 

 

Tending

 

The relationship between code and the organizations that create it is deep. Once you get this, it’s easy to see that what we call legacy code is exactly what you would expect when developer turnover is faster than code turnover.

 

Code lives longer than our time with it. There are systems being worked on now not at the company that developed them but at the company that acquired the company that acquired the company that created them. These systems keep an ecosystem of antiquated tools in use around them as life support. We can take control, and its important that we do. Code’s environment changes. We make new demands on it continuously. It grows and becomes more complex. Eventually, costs increase and we have to decide what to do. Many organizations don’t see alternatives to just carrying on.

 

Biological systems have the same growth issue. Organisms adapt. Every part of every living body adapts to change, but there are limits as the demands increase. 

 

Many biological systems manage this through two strategies: cell death and cell repair. Plants and animals live because individual cells die and are replaced. Each cell is a fresh start. Individual cells repair themselves too. They have processes in place to maintain their health.

 

In software, refactoring is a way of managing health. What we need now are better practices for managing the lifetime of our pieces - for recognizing when it’s appropriate to redirect effort to different feature areas. Or, when to  scrap an area of code and rewrite it. Never-ending growth in code can be a trap. Too many organizations walk into it unaware. By the time they realize they are stuck they are facing the wall of a huge re-write or a multi-phased software replacement plan.

 

Again, continual awareness needs to be part of the strategy. If organizations tend the code and pay attention to its growth, they’re in a position to make conscious decisions to get rid of code when necessary, and make plans for how change should be approached in particular areas of code. A number of people have pointed out that long term software development is like gardening. It really is.

 

I think we need to adopt the attitude of caretakers in our systems. People are important, but we’re one part of an organization. The code is there too and it’s our job to actively tend it.

 

 

Going Forward

 

Symbiosis is a way of seeing organizations that reflects the reality of our impact on software and its impact upon us. 

 

My sense is that we need to have some conversations in the industry about what happens to software development when it is more thoroughly integrated into organizational life.