Inner-platform effect

The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered to be examples of an anti-pattern.

Examples

Examples are visible in plugin-based software such as some text editors and web browsers, which often have people creating plugins that recreate software that would normally run on top of the operating system itself. The Firefox add-on mechanism has been used to develop a number of FTP clients and file browsers, which effectively replicate some of the features of the operating system, albeit on more restricted platform.

In the database world, developers are sometimes tempted to bypass the RDBMS, for example by storing everything in one big table with two columns labelled key and value. While this entity-attribute-value model allows the developer to break out from the structure imposed by an SQL database, it loses out on all the benefits, since all of the work that could be done efficiently by the RDBMS is forced onto the application instead. Queries become much more convoluted, the indexes and query optimizer can no longer work effectively, and data validity constraints are not enforced. Such designs rarely make their way into real world production systems, however, because performance tends to be little better than abysmal, due to all the extra joins required.

A similar temptation exists for XML, where developers sometimes favor generic element names and use attributes to store meaningful information. For example, every element might be named item and have attributes type and value. This practice requires joins across multiple attributes in order to extract meaning. As a result, XPath expressions are more convoluted, evaluation is less efficient, and structural validation provides little benefit.

Another example is the phenomenon of web desktops, where a whole desktop environment — often including a web browser — runs inside a browser (which itself typically runs within the desktop environment provided by the operating system). A desktop within a desktop can be unusually awkward for the user, and hence this is generally only done to run programs that cannot easily be deployed on end user systems.

A concrete example comes from HAL, a hardware abstraction layer for Unix-like operating systems. It was a layer between the udev interface to kernel devices, and (mainly) desktop environments like KDE. After having been introduced with much effort, it is now considered deprecated, because it offered nearly no advantages over just using udev directly, but added much complexity from being convoluted and over-engineered.

The Smarty template system for PHP is another example. It started as a simple template language but kept growing until it started to duplicate all the features of the PHP language it was written in. It could be argued that PHP itself suffers from this effect, having started as a set of Perl scripts, to which features present in the Perl language were progressively added.

Effect

It is normal for software developers to create a library of custom functions that relate to their specific project. The inner-platform effect occurs when this library expands to include general purpose functions that duplicate functionality already available as part of the programming language or platform. Since each of these new functions will generally call a number of the original functions, they tend to be slower and if poorly coded, less reliable as well.

On the other hand, such functions are often created to present a simpler (and often more portable) abstraction layer on top of lower level services that either have an awkward interface, are too complex, non-portable or insufficiently portable, or simply a poor match for higher level application code.

Counterargument

The counterargument is that the creation of an inner platform is usually done for portability and privilege separation reasons — in other words, so that the same application can run on a wide variety of outer platforms without affecting anything outside a sandbox managed by the inner platform. For example, Sun Microsystems designed the Java platform to meet both of these goals.

See also

• Second-system effect
• Not Invented Here
• Greenspun's Tenth Rule
• Zawinski's Law

References

• Original definition and example
• Example: The Enterprise Rules Engine
• Example: I Think I'll Call Them "Transactions"