Stuck with the The Inner Platform Anti-pattern?

Just recently our team has received some innocuous requests from the customers: “please can we have a configurable menu here?” or “...this would save us a lot of time”. These, on the face of it, should have been extremely easy to code, but have turned out to be a real nightmare. At first, I put this down to the massive technical debt¹ of the legacy code we’ve inherited, but more recently, after a comment from a colleague, I’ve come to realise that it’s more than that.

In this particular case, the client uses, and we’re working with, a tool that allows the preparation of content for web sites. This is one of those “one size fits all” scenarios where the tool is extremely versatile and can, using an SQL database and a whizzy front end, be made to do almost anything when it comes to designing a website. Or can it? The downside of being extremely versatile is being extremely complicated, which is where the Inner Platform Effect comes in. This, I think, was first mentioned by Alex Papadimoulis in The Daily WTF, which states that:

“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.”

...which is incredibly similar to what we’re dealing with, except that you need to substitute the word ‘platform’ for the word ‘tool’.

After thinking back a few years, I’ve also come to realise that this “one size fits all” development tool that answers to all your programming needs is also a case of the Silver Bullet Classic Mistake as described in
Rapid Development: Taming Wild Software Schedules by Steve McConnell whereby a company's “management” buys into a tool or technology that its manufacturers claim will fulfill all their business needs. Obviously, there's no such thing as a magical silver bullet and the customer usually ends up disappointed.

At this point in my blog, I usually offer a couple of suggestions for dealing with an anti-pattern, but this time? If the inner platform is all pervasive, under pinning your business needs, then you may be in big trouble. If you recognise that there may be a problem then what choices do you have? You could either:

1. Stop using the tool.
2. Carry on using the tool

Changing tools mid-project is also down as one of Scott McConnell’s classic mistakes. It’s costly as you've invested a lot of time an effort into this tool, but on the other hand if you carry on using the tool, you may not be as competitive and as agile as your business needs demand. A case of Kobayashi Maru?

---

¹As described by Shane Warden and James Shore in their book The Art of Agile Development