why can't software be like an aircraft engine ?

When dealing with software professionals, the users, tend to asks questions like why the making of software doesn't work, exactly like their actual job. And when you make a software for the engineers who design, develop and test Aircraft engines, they seriously ask questions like why this software can't be like an aircraft engine.

I get really excited about such comparisons. When it comes to software, I always hold the opinion that there is no comparison that fits. I wish the poet Pablo Neruda had written some poems about making software. Then, at least, we would not have this shortage of good metaphors.

I wrote a blog entry sometime ago about what I do for a living. I can say it again - RSA wouldn't mind it actually - I work on a team of customizing an Engineering software for an Aircraft Engine manufacturer. We work on a monthly build cycle, that works fairly successful in fixing bugs and introducing a new feature every month. In plain words, we put in a new version of the software every month for our users - with a new major functionality and a few bug fixes.

There are no dedicated testers here. (Yeah, I know. Just give it a break. It's just a customization project). Its the actual users who test it in a simulated test environment, before we push the software to the real time, live wire production environment(Again, with the shortage of metaphors in Software Engineering, we use buzzwords!!!) . In the previous build, it so happened that the testing for the major functionality was complete, but the bug fixes - We couldn't get enough users to test them!!! Obviously, we can't push the software to Production, until we are sure we aren't breaking anything with our "fixes". So we had to delay the build a week. When we told that to our clients, one of them had this to say....

You are saying that you can't push the software to prod until the bug fixes are tested ? Its like saying - Even though the nozzle assembly of the engine has been tested for every other performance metric, and just because a small component such as a bracket is not available, I can't ship the engine. Can't you just pull out the bracket ?

When all of our customization is built and bundled into a single shared library (All of them are in a single binary file), it is impossible to pull the fixes from the dll file. Sometimes, I do wish I have some supernatural power by which I can rip apart the bytes of that binary file, and pull out the ugly "brackets", I wish I had not made. (The main reason would be - save some embarrassment.)

Unfortunately in Software Engineering, we are still trying to figure out how to do things better. And all I can say is that making parts of working software into components hasn't reached the level of granularity of building an engine - to its bolts and nuts.

It is not impossible. (Pardon the double negatives. I need to be explicitly equivocal here.) You just need a highly flexible version control system, probably use a scripting language instead of a compiled language (a framework like Ruby on Rails ???), then a perfect system of tagging, naming, arranging builds, then of course, a reliable system of automated testing, and then finally a highly granular configuration system - seamlessly integrated with the rest of them.

If we can have all that systems, then probably we can "pull out" stuff that is not required. In short, it is just not like pulling nuts and bolts or even a bracket out of an aircraft engine assembly. (Or it could very well be just that the comparison of bug fixes in a software to a bracket in a engine could be wrong. I told you - We badly need Neruda)