The Myth of Custom Software and “The Box”
Up to this point, all of my company’s ASP.NET development work has been either complete one-offs or built on an in-house CMS platform (and I use that term loosely). That platform has evolved as client requests have dictated, resulting in a different codebase for every website we do. Nothing ever gets backported; no old sites are ever updated with the new code. If we did try to backport code, we would probably end up with a broken website, a livid client, and a lot of wasted time. Yes, this has as much to do with our shoddy development practices as anything else. I’ve tried to fix it. Believe me.
The main reason we ended up with a custom CMS platform was the boss’ insistence that we are a “custom software” shop. By this he means that our clients are free to dictate whatever they want, and we will code software to meet their demands (it should go without saying that this has resulted in some truly terrible and shameful debacles when we are forced to enter arenas we have no business being in). Our efforts to get him to let us standardize on some sort of commercial CMS for web development have met with abject failure. He considers a CMS to be a “box”, and he will not consider any box that limits what the client can do.
My argument against this line of thinking is probably offensive to clients and developers, but here goes nothing. Letting a client go wild without any sort of constraints is exactly like letting a toddler do the same thing. That “freedom” to go in any direction and do anything is ultimately very harmful to both the client (the toddler) and the developer (the parent). If you don’t lay down some rules and set some expectations, it will all end in tears/profanity on both sides. I’ve watched it happen.
This immediately begs the question of why am I using Sitefinity for a website. It’s one more attempt on my part to get some sort of standardization going in our web development projects. I think the biggest hurdle to overcome in order to get acceptance for an external CMS is to convince the boss that what we currently use is just another instance of “the box” (gasp!). Our CMS is a box just like any other, only much less mature and full-featured. “Our CMS can be made to do anything a client asks,” I can hear him say. I might respond with “The same can be said for a blank project in Visual Studio.” This idea that our software must be a limitless playground is bogus and is an anchor to progressing as a company (and myself as an individual developer).
In the end, any CMS or Framework is a “box” that is used to constrain and define development. These boxes are not evil! They are necessary tools in the developer’s arsenal. The best boxes are those that provide a floor of functionality, yet they allow the developer to customize and extend nearly out to infinity within them. Sitefinity is one of them, which is why I’m using it to try to prove my point. The website I’m working on has a concept of a project gallery. I’ve filled the requirement by leveraging Sitefinity’s Images and Documents module with a little bit of custom control glue. Managing projects is a manual process. Things do not automatically appear and function when a new image library is made. Could I have made the system automatic and centrally managed? Yes! The budget is not such to warrant an integrated projects module, so I didn’t do it. This illustrates the value of a good box. I was able to quickly fulfill the project requirement using the floor of functionality provided, but I could have expended the effort to build a fully polished and integrated module if the budget and requirements had called for it.
I hope I can show the boss the value of a “good box” with this project. Maybe his aversion to them is based on bad experiences with PhpNuke, I don’t know. All I know is that we can’t keep doing what we’ve been doing, lest I lose my sanity. Becoming a good ASP.NET / C# developer doesn’t involve endlessly hacking away at shoddy code to fend off angry clients.
