We have a lot of vulnerabilities in software, and it doesn’t seem to diminish.
One of the major reasons we have all these vulnerabilities is that every software developer (or organization) needs to develop every darn litte thing itself. IOW, the networking code, the user interaction, the database handling, etc, just to be able to sell that one good idea or process that is their own. A very small part of every product is what differentiates it from the others, while the rest of the product is a rehash of what everyone does and has to do. Nobody likes to do all those parts, but we have to. And that’s where the vulnerabilities appear, in general.
Even though I don’t like the car analogy, I’m going to use it: it’s as if every car manufacturer had to create every high level system itself, like the braking system, electrical system, interior, etc. They don’t, they buy those from a few suppliers that know how to do that stuff right and cheap. The equivalence of APIs and operating systems would be components like wipers, bolts, nut, etc. The equivalence of the network stack would be the high voltage inductor, while the network handling code would be the ignition system.
Actually, it’s a bad analogy. One of the problems we have is that no physical analogy is right for software systems, so we keep misleading ourselves with them. But still, that’s my analogy for now.
We can’t quite yet get to the same level of component reuse in software as car manufacturers can. So every software engineer, in principle, has to create his own ignition system, even if he’s only interested in building his own idea of a sleek sports car. And, sure, his ignition system won’t equal one made by Bosch. Duh.
Trying to teach him how to make perfect ignition systems won’t work. He’ll be bored and distracted from his main interest. So this has to change.
(All the “software components” stuff is/was about this, but nobody has gotten the abstraction level right yet. They haven’t found the right place to cut the cables, so to speak. My feeling is they’ve always tried to solve too many problems in a too general way with all these systems, including Corba, COM, VCL, whathaveyou. Like I’d ever want to use a readymade ignition system in a juice press. Which actually may not even have a fuse box which the ignition system relies on. The analogy turns slightly ridiculous here…)
The other thing here is “complexity” vs “simplicity”. Complexity screws everything up. It causes exponentially increasing development times and bug counts. It makes for fragile systems and maintenance nightmares. But, you say, people want complex software… no they don’t. They want systems with complex behaviour, which is not the same as complex software. You can build very complex systems from a set of simple software units, if you do it right. That way the total complexity of the system increases linearly with size and function instead of exponentially.
This is what structured programming, OOP and all the rest is all about: trying to build complex systems using simple software. The trick is reducing complex processes to interacting simple processes, then treating each of them as a simple subsystem. Surprisingly few development organisations seem to get this and keep on building complex software using these techniques. Personally, I have a very hard time even imagining which system actually has to be built using complex software and can’t be done by a collection of simple software parts. I don’t really think there are any.
Dividing a complex system into simple software parts, if done right, makes each part easily manageable, allows you to divide the development organization into smaller coherent parts, allows easier documentation, easier testing and bug resolution, easier replacement, etc, etc. It’s a boatload of Good.
The current paradigm change (yey, got to use “the word”!) that’s occurring due to multi-cores will actually help. The transition will be very painful (developers and designers seem to have great difficulty thinking of business processes in anything but a sequential fashion), but if we’re lucky, that may be what’s needed. Pain is good.
Short version: you can’t confront “simplicity” with “complexity” without indicating what level of composition you’re talking about.