The Inner-Platform Effect is the tendency of software engineers to design systems that need to be "customizable" to such an extent that:
- The system becomes a poor imitation of the platform it was designed with AND
- The system becomes so complex that any modifications to it must be made by a knowledgeable programmer rather than a customer.
This phenomenon was named by Alex Papadimoulis in a 2006 post on The Daily WTF.
Give Me An Example!
Let's say your customer comes to you and asks your organization 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. They stress that this system must be very flexible, able to handle many different scenarios for many different applications.
So, recognizing that you will need some significant 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 they need 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! Piece of cake!
Congratulations! We just designed a relational database using a relational database!
Why Does This Happen?
This example is the Inner-Platform Effect at its most basic: we modeled our "customizable" system after another customizable system because that's what was most familiar and readily understood by us programmers.
In our case, we designed this new system after a system we understood very well: relational databases. But why would we do this?
IMO we often see this happen when the customer says they want flexibility but don't (or can't) explain why or for what purpose. The programmers or designers, then, assume maximum possible flexibility because they don't have good, specific requirements and therefore think that they must account for every possible scenario, regardless of whether it is likely to happen. Because we don't have time to think through all of those possibilities one by one, we base our design off of a flexible system we're already familiar with.
How Can We Avoid This Anti-Pattern?
By asking why the customer needs such flexibility.
If the customers need these kinds of customization options, they should be able to justify why they need them. Often this will take a lot of back-and-forth between customers and programmers, but eventually the two groups need to have an understanding of why the flexibility is needed and what that means in terms of trade-offs.
It's also entirely possible that the customer doesn't actually need such great flexibility, but rather they don't know how to explain what they really want so they just say "make it do everything."
Further, programmers can try to be aware of when they are becoming architecture astronauts and letting the design get in the way of a concise, optimal implementation. Remember, if you think something might be useful but can't prove it or justify it, you aren't going to need it.
In other words, this anti-pattern can be reduced (or eliminated) by two methods working in tandem:
- Requirements gatherers need to do thorough reviews of what the customer actually wants and why they want it.
- Programmers can keep YAGNI in mind.
Have you ever seen this anti-pattern in the wild, and what did you do about it? Sound off in the comments!
