Trapped by ‘All in one’ Solutions

Starting out many years ago as a developer it was good fun trying to develop solutions that could be used across multiple websites. This was a great idea in the beginning. The challenge was to try and build some code that could be used over and over again for multiple clients thus streamlining the development process and faster project turn around. As the project progressed and the clients requirements shifted for each project, rather than building a whole new solution for them we would take some existing project and add some modifications to it. Fantastic! All the clients on the same platform would also benefit. Then we could promote our newly updated piece of software as a ‘all in one’ solution capable of delivering all the client’s needs.

How could this have ever been a bad idea? Well, like most ideas that seem good to start with ( like communism ) they can get a little out of hand when you try pack more features and configurations into a system than it was meant to handle. Consider trying to pour 100 gallons of fuel into a 10 gallon drum. Sure, we all need fuel to drive our cars but you don’t need all 100 gallons at once and then you just end up wasting 90 percent of a good thing. Once such ‘all in one’ solution that takes the cake for me would be that wonder of a CMS called ASPDotNetStoreFront.

While I can see that they had the best intentions of creating an online shopping experience with customization of products and other product purchasing functions they seemed to have lost sight a long time ago of it being a usable environment. Many, many MANY hours were lost trying to find the most basic configuration of displaying products on the screen. For some reason the .NET framework was not good enough for ASPDotNetStoreFront. To figure out how their code ( riddled with commented out code by their own team and notes on how a section should be removed later ) worked was a hard lesson in how to create a bloated solution. By packing so many features into the site it become impossible to see where one feature ends and another begins. Hundreds of configuration variables and configuration strings for user content are what you get to sift through before your site can even begin to make sense. There are so many features that by the end your left just clicking buttons in the admin and changing settings just to see what happens. And then you wonder if it’s even what you were looking for in the first place. I can go on and on about their wonderful idea of XMLPackages to display content that require extensive knowledge of XML or the fact their older versions can’t run on modern systems due to their code hacking a previous security flaw but that would be too exhaustive for this blurb.

I guess there are probably hundreds of such CMS sites out there that claim and fail at the same practice of being ‘all in one’. Yet where ASPDotNetStoreFront fails the most would be in just having too many options available. As a user and even as a developer trying to use the system you just end up with a product that only the people who wrote it can figure out and that does nothing for promoting your product. Clients want to feel they can learn how to manage their site without feeling their going to lose part of their soul in the process and feel they can do all they require and nothing more. When you end up trying to over compensate for everybody you end up confusing everybody and then it’s too late to go back without re-inventing the wheel. The best solution is to build systems that can be re-used without having to drag down the rest. Everybody likes a plug-in. All developers just need to remember their COMP101 lecture and the best acronym of them all K.I.S.S. Which is also a great band.