It’s Not Like Construction! – InApps Technology 2022

Perhaps the best way to see the critical importance of effective software development in the modern world is to look at Netflix. In 2009, WSJ columnist Martin Peers argued that Netflix was at its peak:

Hollywood studios appear to be waking up to the threat posed by Netflix’s instant-watch service, which the company says is being used by millions of its subscribers … [S]ome of the studios are pondering their online movie- or TV-subscription services.

But here we are, and today Netflix’s stock is trading more than 700 percent higher than when Peers wrote that column. Netflix survived for long enough of a middle-man in delivery of content to consumers that now it is a content producer in its right (and much harder to disintermediate).

So what happened to those studio-backed movie and TV subscription services? Disney (mentioned in Peers’ 2009 piece as a company considering one) launched its service… in 2015. Starz (the source of much of Netflix’s content) launched theirs… in 2016.

Peers’ assumption — and still the assumption of so many people, both technical and non-technical, is that it should be fairly simple just to go build some software and launch a service. That’s a bad assumption.

Good Software Is Hard to Write

The reality is that building good software efficiently is hard. And the difference between the average product development team (meaning both product and software development personnel) and the best is absolutely massive. The best lets Netflix launch and scale its service quickly and effectively; the average results in many years from conception to delivery of a significant new software-as-a-service at an enterprise.

Note that I am not talking solely about the “10X software developer” here — this as much about the product personnel and the way the team works together as individual developer talent.

The reality of highly effective software today is that it changes constantly.

And the average is far closer to the worst than the best: my copy of Dashlane password manager gets less usable and less stable with each release. Concur, the software through which I have to submit my receipts, crashes when I upload a receipt with Chrome, the most popular web browser in the world. Salesforce still takes millions of clicks to put in or retrieve information.

This is all the more embarrassing, given that software is eating the world and the most effective companies are the ones that can most effectively develop software — or at least leverage existing software to get things done. (And the above-mentioned companies with mediocre software are successful ones!)

The best way to understand how software development has changed in the past 15 years is to look at it as a popular analogy for software development in the physical world.

Prepare for Constant Change

Fifteen years ago, comparing software development to the construction residential or commercial structures was a pretty good analogy. The general idea for building both with the same: you would plan completely, upfront, what needed to be built and you would have lots of stakeholders approve the exact thing that would be built. And then you would go through a long period where you would build the thing, and then it would be done just as it had been laid out in the plans. And any future modifications would be relatively small scale in light of the overall footprint of the building (like interior remodeling vs. changing the exterior structure).

The reality of highly effective software today is that it changes constantly. Even two years after the initial release, highly effective software has many additional features and is easier to use. The most obvious characteristic of highly effective software is that it is constantly changing and that there are very frequent releases: think of how Chrome updates itself or how Facebook does multiple releases every day.

So the traditional analogy to constructing a building is no longer appropriate if what you want to do is to develop highly effective software today.

Please note that this requires a really substantial shift in thinking that many professionals who have presided over software development projects of the past simply are unable to adjust to. This applies to both technical and non-technical professionals alike.

But so many executives both technical and non-technical, still generally think about the physical construction analogy. They also continue to use the same tools that they have always used and that also lets them down in substantial ways when compared with highly effective software development.

I have written on a number of the reasons why technology executives and developers and professionals tend not to update their skills: fundamentally, there is no real mechanism in the industry that is helping people stay current. But there is also another reason, which is that the advances that have been made in software development over the past 15 years have been iterative. And that means that each advance wasn’t necessarily a dramatic improvement from the way things were done before.

Evolve, Don’t Construct

So, for all those who have been involved in software development for at least ten years, let’s step back and walk through why building software is not like constructing buildings:

The most important difference to understand between erecting a building and creating software is that physical construction is a capital project, whereas building effective software is much more of an ongoing operational project. The older view of the living software is based around the idea that you essentially lay out all of the key architecture and infrastructure and elements in a bigger piece of development, and then you do some additions and add more features.

Modern, effective software development gets the software out to the customer as quickly as possible and is happy to downscope viciously to do so. This means that the first version that customer see is never a complete anything. If you are re-writing an existing system with modern software development, you necessarily are targeting a subset of users with a subset of features. And then you are using the development capacity (also known as velocity), and frequent releases and the interaction you can get with your users and their immediate feedback, to iteratively build software that is much more responsive and much more delightful than it would be otherwise.

Again: this requires a substantial shift in thinking that many professionals who have presided over software development projects of the past simply are unable to adjust to. This applies to both technical and non-technical professionals alike.

Technical professionals often over-engineer solutions. This means that when a specification comes down for v1.0, technology professionals often want to make sure that whatever initial architecture and technology is chosen to implement the specification can last for years and years like one would choose building materials for a structure.

But more often than not, the specifications are deeply imperfect. They are based upon assumptions around how the users will want to use the software and they almost always fail to take into account any really deep understanding of where the user might be going in the future.

For example, it would have been hard in 2007 to have predicted the complete ubiquity of smartphones. The application platform backend and middle tier that is needed for desktop experiences with high-speed internet are not the same architecture and back end needed for mobile devices with intermittent connectivity issues and slow JavaScript rendering engines. And the way one best handled those mobile users in 2013 was quite different from the best practices of how to handle them today. So trying to set up technological architectures to last without change for 3+ years is to doom your software to mediocrity.

Non-technical executives also have difficulty understanding how software can be built iteratively as a function of velocity and releases, as opposed to a grand vision from a product genius. This is especially difficult when building a software product that is replacing a legacy software product. But the reality is that everyone has been trained by the best software developers in the world to get iterative releases. We all understand what a beta version is today. Many people understand the Product Hunt world where people thrive on getting early access to new versions of software so that they can be part of influencing that software’s future roadmap.

And because we can segment users so easily in the modern world, we can make beta versions available to subsets of users very easily so that when we need to deliver software out to users who only want rock solid stable versions, we can do so at a marginal cost of zero. And, if we have validated every iterative release off real users who are similarly situated to the users with rock solid lock down needs, we will have dramatically higher confidence that when we do release the formal, stable release, it will be what is needed.

In the world of modern, effective software development, the two most important metrics are the frequency of release and the velocity of development. If your organization is releasing new versions to customers very frequently and your developers are adding good new functionality with each release, then you can build software the way software should be built.

If you understand the difference between building software as a capital project like a structure, versus building software as a function of velocity and frequent release, then the next question you may ask is, what are the processes one can use to actually do frequent effective releases?

And that is a great question because it takes using modern software development processes to be effective. You cannot use the software development lifecycle of 2005 and expect to have an effective velocity with frequent releases. I will talk about the specific processes in my next posts.

Feature Image via Unsplash.