How to explain modern software development in plain English

What is software development? A key to competitive advantage. Here’s how to explain today’s development realities, including why cloud services and containers are key to developer velocity

Some principles of software development – also known as programming – don’t ever really change.

Programming is problem-solving. Programming is communication, albeit with a machine. Programming is what makes that machine – and millions of others – usable to the masses. Programming is imperfect, always a work in progress. Programming is work.

Preface the longstanding term with the word “modern,” however – as in, modern programming or modern software development – and you are in fact saying that things have changed. It might suggest there could be pre-modern and even ancient phases of software development, as if we’re talking about art history instead of computers and software.

The term “modern software development,” in particular, gets thrown around with semi-regularity. It’s indeed used to convey that the speaker (or writer) is referring to software that is being built and operated today as opposed to at some unspecified point in the past. While some core principles might not waver, much of today’s software is being built differently – and more quickly – than in the past.

[ Want a shareable PDF of this entire article? Download it now. ]

Developers are breaking things into smaller pieces, for example – the applications you or I use on our phones and laptops every day might actually be composed of many smaller applications, even if that’s not visible to the untrained eye.

Moreover, developers increasingly write code without a great deal of concern for where it will run – because it will be packaged and deployed in a way, known as containers – that promises it will run consistently in virtually any environment (more on that below). For some IT pros, this is, well, different than when they were first getting started.

On the other hand, programming really hasn’t changed at all, as evident in this wonderfully simple definition of software from Mikhail Opletayev, CTO of Capitol Canary: “Software is a set of instructions that tells computers what to do.”

This was true 25 years ago, and it will be true in another 25. Software is the stuff that makes machines – and most businesses these days – run.

“Whether it is showing a web page or rendering a CGI effect in the latest Marvel movie, it all boils down to an engineer writing a set of commands in a special language that computers understand,” Opletayev says.

Again, what has changed is how those engineers write their code, and what happens to it when they’re done. Here’s a quick primer on the fundamentals of how software development has evolved – and how to explain it to non-technical people in your broader organization.

Modern software development is faster and more iterative

Software development – the effort needed to produce those instructions that tell computers what to do, as Opletayev says – used to be done in what is commonly called a “monolithic” fashion. That means the entire application is built from scratch, piece-by-piece, bit by bit. Later, when new features or changes need to be made, you deal with the entire application again – touch one part, touch ‘em all. (People who own an older home might understand the monolithic application via a "This Old House"-style analogy: Replace that shabby old hardwood in the dining room and you very well might find out you need all new subflooring and mold remediation, too.)

[Also read Continuous integration: 5 key success factors. ]

Monolithic software was also typically built to run in very specific environments – such as on an end user’s laptop, or on a physical server running a specific operating system, and so forth – and that’s it. If you want it to run elsewhere, you’ll have to (re)write more code and likely then have multiple versions of what is effectively the same app. Monolithic applications certainly still exist – but this is no longer the only way. Moreover, software can now be written once to run virtually anywhere.

In the simplest terms, here’s what has changed:

Modern approaches (like DevOps) and architectures (like microservices) have enabled software development teams to build software faster and more iteratively – you don’t have to wait months to ship a new feature because you can simply write and ship that feature rather than tinker with the entire system.

And you don’t have to worry as much about different environments, thanks to containers – which allows developers to package up their code and all of the other components and dependencies it needs to run, regardless of the environment, in isolation. That means the same containerized application should run the same on the developer’s laptop as it will on a physical server in a datacenter as it will on a virtual machine in a managed cloud environment.

You don't have to wait months to ship a new feature because you can simply write and ship that feature rather than tinker with the entire system.

Non-technical folks might get this concept more clearly with a bit of nostalgia. Ravi Lachhman, field CTO of Shipa.io, uses the childhood game of telephone, in which the first player might whisper to the second, “Blue is my favorite color” – which morphs into “Blue ice cream is interesting” by the time the message reaches the _N_th player down the line.

If instead of whispering, you simply wrote the message down and handed it down the line, it wouldn’t be much of a game – but there would also be no confusion.

[ Also read 6 things you can do with agile right now. ]

“Software development is, in some ways, similar to a game of telephone,” Lacchman says. “With all of the dependencies and configurations that an application needs to get out in the wild, recreating that environment-to-environment (like going person-to-person in the game) takes time.”

Containers – along with a host of other technologies and a general move away from manual work in favor of automation wherever possible – is akin to simply writing the message down so that it will never be misunderstood, no matter how far it travels. This saves an incredible amount of time and allows for much faster, more frequent updates – think in terms of days or even hours, not months.

“Building and shipping exactly what you need, with the velocity of containerized infrastructure, decreases the need for interpretation and is certainly a ‘cheat’ for developers’ software development speed,” Lachhman says.

Modern infrastructure has evolved, too

The increased velocity produced by new ways of writing, packaging, and deploying software gets some serious tailwinds by changes in the infrastructure that software runs on.

The basic principles here remain true: “Once software is written by engineers, it needs a computer to run on,” Opletayev says. For some software, that means a phone or a laptop; other software runs on more powerful computers called servers; and still other software runs on both. Opletayev gives a timely example of the latter: “For instance, Zoom runs on your personal laptop and it operates many servers to connect the calls.”

For a long time, those servers were physical machines that either sat in the corporate office or datacenter, or perhaps in a colocation or hosting facility somewhere else. But then the cloud came along and changed everything.

With cloud computing, companies could rent servers instead of buying (and maintaining) them – not to mention a whole host of other infrastructure and services. This was a game-changer – it made the raw IT firepower once reserved for the world’s largest businesses and governments available to pretty much everyone. And even for those massive companies, it brought new economies of scale – and much faster implementations – that would have once been unattainable.

“As companies grow and require more computing power for their software, installing it on each server becomes very tedious and time-consuming,” Opletayev says. “Instead, it can be packaged with all libraries and necessary dependencies into containers and easily deployed across hundreds, or even many thousands, of servers. Where it could take months to build out a data center 20 years ago, today a large solution can be deployed with a few clicks, leading to great increases in productivity.”

"Where it could take months to build out a data center 20 years ago, today a large solution can be deployed with a few clicks, leading to great increases in productivity."

You can’t overstate the significance of this change – it turns out that the “modern” in modern software development is a really big deal.

Lachhman serves up a delicious metaphor to help explain the significance of cloud infrastructure and services to non-technical folks: a pastry chef baking cupcakes. As a dedicated professional, the chef wants to use the best ingredients (code and other software components) and tools (infrastructure and related services) available. And they don’t have an endless amount of time – their customers are hungry, and if you don’t deliver the sugary goodness they want, they’ll go somewhere else.

So the baker uses an automatic mixer instead of a spoon, and they use an oven instead of building a fire outside. And here’s where Lachhman’s metaphor really clicks: The chef buys the eggs from a store instead of raising the chickens that produce those eggs.

Chickens are wonderful animals, but they’re work! They require care, feeding, and housing; they can get sick and they, like all living things, will eventually die. A server room is cleaner and smells a lot better than a chicken coop, but the comparison is otherwise on target – as are the modern, automated tools of the baker.

“All of these conveniences allow you, as a pastry chef, to innovate on the cupcake flavor – and fine-tune as needed – without the toil of having to recreate the egg,” Lachhman says, adding: “Cloud services provided exactly that: The raw materials that developers need to run and power their applications.”

Software development processes, methodologies, and culture have improved

The first two tectonic shifts in software development necessitated new ways for teams to work together.

While a generalization, IT teams used to be much more siloed and disparate. Developers did their thing, then handed off the code to IT operations (aka infrastructure operations) and never thought about it again. Testing/QA, security, and other roles similarly only touched the software when it was “their turn” and did so in a piece-by-piece, monolithic process. Sometimes those teams didn’t even sit on the same floor or in the same building.

While distinctions between job roles certainly remain, modern software teams have become much more heterogeneous and integrated. The boundaries between job functions aren’t as rigid, shared responsibility is now a thing, and testing and security are (hopefully) not rudimentary checks before a Friday afternoon deploy.

While distinctions between job roles certainly remain, modern software teams have become much more heterogeneous and integrated.

“Building large systems requires more than one engineer, which in turn requires companies to have processes through which the work of multiple people or multiple teams are coordinated. In today’s world, most companies use a process called agile,” Opletayev says. “It allows businesses to quickly adapt to the fast-changing market and ship software that their customers need.”

There are multiple flavors of (and even more opinions about) agile, but suffice it to say it’s a good proxy for processes, methodologies, and cultures that engender faster, more cohesive software development. DevOps – and its sibling DevSecOps – is another major example. CI/CD is yet another (related) example.

Modern software development is more deeply connected to business value

Pick your axiom – software is eating the world, every business is a software business, etc. The idea is simply that software is vital to virtually any organization – small or large, public or private, or by any other measure – operating today.

What this means for modern software development is that it has become – or should become, in the case of laggards – much more clearly linked to business impact. The value of all of the above isn’t intrinsic – it’s in the outcomes these evolutionary changes enable.