Now, Im no software engineer. So I wanted to relate Software Design to something I do know. Here's what I found:
Curious about where it all began, I started looking in the most erudite collections of lore on the subject of software's history. My research came back surprisingly thin, I'm afraid. It seems searching any combination of words on Google right now returns only blog postings about the iPhone, why not to by the iPone, and countdown clocks to the exact moment you can say you didn't buy that iPhone.
When that didn't work, I decided to ask a fellow highschool alum for a quick history lesson. Apparently it started in the 80's when some kid wrote something called BASIC for a toaster with lights and ended just recently with something called .NET for Vista. Seems after that latest product shipped, all Java and C++ programmers simultaneously quit their pointless jobs.
Now, the Networking World isn't nearly as fragmented. You have Cisco. Then you have other guys who aren't. I've worked with them all, and it really doesn't matter what product you buy. Given a little time and support, most anything will talk to anything else. Not that they want to, mind. Its the protocols that force the issue and make networking companies try to play nice. Networking protocols are no different than other, more commonly accepted rules. For example, protocol in the US says we drive on the right, the steering wheel is on the left, brake is next to the gas, cub holder is too small for a Slurpy. No car company would break the common protocol, even if they could. That means I can drive my Taur-ass 364 days of the year and my wife's sick CR7 one day of the year and not wreck.
Software Engineering is coming around with Distributed Computing and Component Driven Design. The idea being we should maybe think more about how our shiny new app will play with those forty other shiny new apps. Every application should look to how it will share its information or service with others, typically by using messages sent within a standard (or protocol) for communicating information. Unix had it right 30 years ago in its philosophy that you don't bolt on functions to a tool, you build a new special tool and let it communicate its results with its peers.
So if software was market driven to follow protocols, we would see more applications that had to follow basic SOA methods before they left the drafting board. That would mean buying application (or building them) that just enough to fill your need. No waste, no want. It also lets you use the right language for the job without sweating the previous environment. Or even, dare I say, upgrade your toolbox by working with fresher languages and just plugging it into your systems. Certainly your exposure to risk is lower when you only have a small application tying into the Distributed Computing net.
Oh, man. My programming team is going to hate me.