Interfaces, specifications and DNA

Modularity and open source go hand in hand. There are several reasons for this: coding relatively small sub-assemblies to strict interface parameters works well for small teams of programmers. Published interfaces are the sine-qua-non of...

Share

Modularity and open source go hand in hand. There are several reasons for this: coding relatively small sub-assemblies to strict interface parameters works well for small teams of programmers. Published interfaces are the sine-qua-non of openness.

Creating a plug-in specification (a la Firefox) is a way of inviting people to add to your code (without really adding to your code).

So when I met Patrick Andrews recently to talk about recent developments with the 40Fires/Riversimple open source car project, I was happy to trot out my usual diatribe about the benefits of standardised interfaces and modularity to the open source style development project.

After all, if you can have a standard fitment for connecting a brake disk to hub, for example then it makes it easier for teams on either side of that interface to build to that interface. Stands to reason.

Patrick stopped me right there: he told me that Hugo Spowers (the founder of the project) was adamant that one of the things wrong with modern car design was that there was too much standardisation and modularity. A car is not like a computer system.

The digital overhead of even additional megabytes of unnecessary interface implementation is relatively unimportant in comparison with the physical metal required to create vastly over-specified mechanical interfaces for brake disks and suspension components.

It's interesting to note that evoution, usually that most parsimonious of engineers, is quite happy for us to wander around with up to 98% of the DNA in our genome not coding for anything.

Once more, rules for the physical world don't map onto the digital world.

Promoted