The Inner Platform Effect is an anti-pattern that occurs when a software system is designed to be so customizable that it ends up being a poor imitation of the platform it was designed with. Because of this, it then requires an experienced programmer, rather than a customer, to make changes within the affected system.
This pattern is insidious, because it often happens without anybody noticing until it is too late. The solution is simple: probing.
No! Not that kind of probing! The conversational kind, not the extraterrestrial kind! Good lord!
The Rundown
- Name: The Inner-Platform Effect
- Summary: A system which becomes a poor imitation of the platform it was designed with.
- Type: Software Design
- Common?: plugs in probe Let's find out!
A Brief History
This is one of the more recent software anti-patterns to be defined and given a name. It was cited by Alex Papadimoulis on his blog The Daily WTF in 2006, where he provided the following definition:
"The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with. This "customization" of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it."
Give Me an Example!
"Those who do not understand Unix are condemned to reinvent it, poorly." Henry Spencer
Let's say your customer comes to you and asks you to build a system that will allow them (the customers) to create web pages with inputs such that they can design their own forms, their own surveys, their own blog posts, etc. (Yes I know this is contrived, work with me here.) Your customer stresses that this system must be very flexible, able to handle many different scenarios for different applications.
So, realizing that you will need some serious control over what can be displayed to the user and what fields are shown, you create the following database schema:
Now, we can allow the customers to build anything they like! All our customer needs to do is define their pages, then add their fields, and we can write code so that we place those fields on the pages and store the data in another table, probably called Data. That shouldn't be too hard, right? And even if it is hard, we can just do it for them, since we understand how this design works! We don't even need them.
Congratulations! What the customer wanted was a content-management system, and we designed a relational database... inside a relational database.
When Does This Happen?
Often the Inner-Platform Effect comes to fruition when either the customer describes a system that is super generic and tries to solve many problems at once (and the developers don't point this out), or when novice programmers design systems that are far beyond their experience level, in which case they accidentally end up building the system they're already familiar with.
The tricky part is that the Inner-Platform Effect is almost always accidental; nobody sets out to re-implement a system, rather they're just trying to solve a problem that is probably not defined enough.
Strategies to Solve
As with many of the other anti-patterns in this series, you have to fix the Inner-Platform Effect before it ever starts, and you do this by probing them by asking controlled questions, and specifically, by asking why.
Ask them what they're trying to solve. Ask them what problems their company is encountering, and why they think this solution will provide the biggest bang for their buck. Ask them to identify the biggest pain points, and then work together to solve those points individually, only later trying to see if they fit together in a sane fashion. You are, in effect, trying to piece together a puzzle, and only when you have enough pieces will you be able to see the picture.
Knowledge never hurts; at the very worst it can only be superfluous, and in this case you need all the knowledge and awareness you can get to solve a problem that isn't being adequately defined. Once you have the appropriate problem parameters, you can research and select the appropriate solution architecture, rather than trying to design something super generic and ending up with another example of the inner-platform effect.
Summary
The Inner-Platform Effect occurs when developers build a solution that is an accidental copy of the platform they use. This can be due to inexperience, or to not asking enough questions. As with many of the Software Design anti-patterns, the solution is to probe. Gently, of course.
Did I miss something? Do you have a better definition of what the Inner-Platform Effect is? Did I accidentally make this post a relational database? Let me know in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
