Adios to “computer programming”

Have you noticed how seldom people put the modifier “computer” in front of “programming” nowadays?

This may be because our formerly esoteric discipline is now so mainstream that it needs no elaboration.

It may be that we’re all growing lazy.

But I think there’s something deeper.

“Software Engineering” isn’t good enough

The set of things besides traditional computers that need to be programmed is growing by leaps and bounds: TV remotes, holiday light displays, e-readers, smartphones and tablets, Arduino boards, fuel injectors, point-of-sale terminals, MRI machines, 3D printers, LEGO MindStorm robots, networks (software-defined networking / SDN), storage (software-defined storage / SDS), nanobots, social networks, clouds…

Nanobots replicating in a petri dish. Is it fair to say we “program” nanobots? Photo credit: PhOtOnQuAnTiQuE (Flickr)

“Right,” I hear you say. “That’s why I like the term software engineering. Wherever you see programming, it’s software that’s in play. And engineering implies a more sophisticated approach than mere hackish programming.”

Okay.

I think that’s true, but it misses the really big insight.

Systems thinking is the wave of the future

Technology is evolving–rapidly–to depend upon complex systems, not isolated devices, as the dominant unit of value delivery. More and more often, programming tasks demand a greater scope of design than a single computer.

That’s big.

The TV remote isn’t programmed in isolation anymore. The vendor of the TV also has to provide a whole firmware update process; has to provide a way for the remote and the TV to interact during configuration; has to think about users who want to upload profiles of their remote settings to the company’s web site, so they can be persisted across upgrades and converted into equivalent choices in a smartphone app.

Nanobots achieve goals as a swarm.

3D printers have user forums and public blueprint-sharing sites and import-from-sketchup features to support.

Auto manufacturers have to release replacement parts on a schedule that correlates to the upgraded diagnostic features and the bug fixes they offer for their onboard computers.

Implications

Germ theory revolutionized medicine; mortality rates plunged as doctors acknowledged for the first time how hand-washing translated into better recovery from surgery.

Software is just as interconnected. Individual chunks of code depend on one another being alive, can poison one another’s environment, must respect the constraints implied by one another’s requirements. Engineers and architects and CS professors, we have to stop thinking at the level of a single app(lication). We know we need the databases behind our app(lication), the web servers that host our UI, the people that maintain our infrastructure… When we pursue “integration” we acknowledge that we’re joined at the hip to other products. Cloud computing makes our dependence on the internet explicit.

But do we get it?

We need system thinking baked into our industry. We need programming languages that have sufficient expressive power to model entire ecosystems, in all their chaotic and evolving complexity. We need development processes that are agile for ecosystems, not just for a feature of an app.

We don’t use the term “computer programming” much anymore, but when are we going to start talking about “software ecosystem engineering” instead?

Until we do, I think we’re missing the boat.

Action Item

Discuss the idea of ecosystems in software with a colleague. How do you see the metaphor relating to your day-to-day work?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s