Software development is exploding. If you spend any time around educators you hear the story — everyone should learn how to program. When I started programing and decided I wanted to make it my career, a friend told me I was foolish. He said that within five years all of the useful programs would be written. That was decades ago. Needless to say, he was wrong.

 

At the time that I’m writing this software development shows no sign of being supplanted by anything else. Until computers become aware or far more adaptive, humans will need to bridge the gap through programming. In the meantime, individuals, societies, and businesses are on an treadmill. Software has allowed entrepreneurs to create businesses like Uber that were unimaginable 20 years ago, and software-fueled businesses like Facebook and Twitter have had deep effects on our social interaction. Software changes us as much as we change it, but there are exceptions.

 

Many businesses are struggling in the face of rapid technical change. It’s normal and expected. Some do very well. The ones that don’t are often impeded by deep cultural issues. The first time I noticed this I was visiting a telecom hardware manufacturer. I suspected that software development actually consumed a larger part of their budget than hardware development but their software projects were doing poorly. Software development just wasn’t in their DNA. They saw themselves as a hardware company and software took the back seat. As a result, software development was something that the organization did but they did not see it as a vital competency.

 

As a consultant, I distinguish between two types of companies. There are companies that see how software is woven deeply into the fabric of the business, and companies that don’t. Some of this correlates with business sector. We can take banking, insurance, and hardware as examples. Each of these domains have deep history and each of them require the development of software to create products and compete in markets. A company starting today in any of these domains has the choice of seeing themselves as a software company. If they do, they have an advantage over companies that see some other part of their business as primary — and sense that, coincidentally, they need some software to keep it running.

 

The distinction between these two frames is crucial. Software is both the skeleton and the nervous system of many businesses today. Companies develop it themselves or outsource it. In either case, they increasingly depend upon an understanding of the relationship between software and the organization around it. 

 

§

 

Decision-making in business is all about dealing with incomplete and possibly incorrect information. If you’re a decision-maker you come into contact with people with various different kinds of expertise. You have to learn from them what is possible and when. Accounting or regulatory people within your organization present you with date and compliance oriented constraints. These areas are frustrating because they are often fixed. In many cases you can’t add staff to make things go faster or seek alternatives to avoid a filing date — you have to work within those bounds. Other areas of business are soft. You hire someone to get a job done and they staff teams to do the work. Maybe it’s creating a new product, service, or campaign. You see the people, and you see how much you pay them. Your view of the organization is: teams and projects. You focus on them and use various levers to keep your initiatives headed in the right direction.

 

But, what if this view of your organization is wrong? Okay, maybe wrong is a bad word. Maybe we should say incomplete.

 

If you’re an organization developing software, staffing and projects are just the tip of the iceberg — they are only part of what you need to know. Actually, I’ll go further — they are a deceptive view of your organization.

 

People in your organization are making decisions today that impact what you will be able to do in the next five years and at what cost. Software is a great enabler but it also imposes constraints, and often they are silent. You don’t know about them until you change course and ask your technologists how long it will take to react or how long it will take to get an unexpected feature to market.

 

The reason why this happens is simple — in technology we rarely start from zero. The choices we make persist in the software we create.  As long as that software exists, it’s organizational memory. It makes some things easy and other things hard. Software isn’t a mechanical thing. In an odd way it’s alive. It grows. When we modify it, it reacts to us. Because of its presence, its value, and its constraints, we react to it.

 

I see our relationship to software as a symbiotic relationship. As in biology, both parties can benefit. We just need to tend the relationship. And, to do that, we need to be aware of what software is, how it grows and how the minutiae of choices we make in terms of process and organizational structure impact it. And, further, how it impacts us.

 

§

 

Some companies today literally don’t realize that they are developing software. A small retail store hires someone to create their website but then takes care of the maintenance themselves. They learn enough about development tools to make some modifications and they are happy. If you ask anyone in the company what a version control system is, they don’t know. An employee learns how to make changes and the business owner knows enough about programming spreadsheets to create the five they need to run the business. Ask them if they are software developers and they’ll laugh. Software change is something that they do but it is not their focus. They only know enough about it to become deeply frustrated with computers. Periodically, they think about buying “a solution” that will “automate their business.” Maybe they do, and maybe they don’t. There’s frustration on both paths.

 

Many businesses today are larger scale examples of this small business. They see their domain — retail in this case, and recognize that they have to develop or customize some software themselves.

 

This is the genesis of the traditional business/development split. The business needs software so they hire programmers and put them in a separate part of the organization. It doesn’t matter whether the business needs the software for its own operations or whether it sells the software or its capabilities to customers. The split is there and it is a communications chasm that the company has to bridge continuously.

 

If one group of people does market research and makes product decisions, and another group develops the software, we have less integrated understanding. The fact of the matter is, if business people work with technologists every day,  they’ll have insights about technology that technologists miss. Technologists will also come up with novel product ideas or ways of finessing systems to generate more value if they become involved in the business. You don’t achieve these effects by having more meetings. You achieve them by working side by side. Or, at a deeper level, by being a business person who writes code, or a technologist who does market research.

 

 

§

 

The odd thing about this split between business and development is that you can see it in the code. One of the key insights in software development is Conway’s Law. It states that the structure of what we produce ends up mirroring the structure of the organizations that produce it. Conway’s Law is a deep insight and there is much more to say about it but with regard to the business/development split it tells us that we should expect poor quality software when there’s a handoff or any gap in knowledge between groups.

 

The tragic thing about this is that it affects what a business can do over time. In many organizations, code lives forever. Misalignments between business knowledge and development knowledge persist in the code. We work around them and, more often than not, end up building on top of them rather than fixing them.

 

§

 

Once you understand the Conway’s Law many things that seem surprising about software development make sense. When many teams work in the same code base, able to touch any part of it, there’s a tendency toward the Tragedy of the Commons. When individual teams concentrate on their own area of the code, the code reacts by modularizing over time.  Process impacts code too. Frankly, everything does. This makes it important for us to have awareness of these effects. Sadly, most businesses don’t. At the highest levels, most organizations have a view of the work that needs to be done, and a view of the organization, but seldom the code. They almost never see them as a whole, and they miss what the code can tell us about long term health — the ability to keep this ecosystem running and delivering value.

 

What happens when we surface this knowledge? When we see the software systems we produce as a part of the organization?

 

There are some implications..