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…
“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.”
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.
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.
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.
Discuss the idea of ecosystems in software with a colleague. How do you see the metaphor relating to your day-to-day work?
- Principles of Software Engineering, Part 1 (nathanmarz.com)
- The Paradigm of the Software Developer: the Engineer vs. the Artist and How it Affects Software Development (kennethmiralles.wordpress.com)
- The origin of “software engineering” (bertrandmeyer.com)