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.

Code vs. Documentation

I’m evaluating Telerik’s Sitefinity CMS by reimplementing one of our older websites with it. I’m a C# / ASP.NET fan, so the system is right up my alley. What the guys in Bulgaria have managed to create is nothing short of amazing, but I do have a beef with them…

The documentation is woeful!

Believe me, I understand that writing documentation sucks. I’m not any good at it myself. However, if you’re writing a framework within which others will be working, you have to pay attention to it in order to give your users some kind of roadmap! Sitefinity is a huge ball of providers and override-able classes. The current version is 3.7 SP2. The online developers manual is for version 3.2. The software distribution didn’t come with one at all. Incidentally, there was a major architecture change in 3.6! I did find a partial ersatz developers manual on the Sitefinity blogs, and I was eventually given a link to a chm version by a very helpful dev on the forums (more on the forums in a minute).

Now yes, I did eventually get the information I needed from the manual I downloaded. It shouldn’t have been that difficult though! One dev on the forums said that the reason the documentation is so sparse is because the pace of development is so fast. I understand this to a degree. It doesn’t feel like there’s much point in writing documentation that will soon be out of date. I maintain that there is a point. Writing a framework for others to use is like leading a spelunking expedition. The documentation for the framework is the light on the follower’s helmet! It doesn’t matter if you, as the leader, know where you’re going if you don’t give your followers the necessary tools to follow you and avoid the large hole you just hopped over.

Now I’ll take this little scene one step further and bring in the Sitefinity forums. The forums are a rope that everyone holds onto and that keeps them attached to the leader. If you get stuck, the devs on the forums are amazingly responsive. Sometimes they will even code custom skeleton solutions to your problem! I have nothing but the highest praise for the devs that work the forums, they are an invaluable resource to those wishing to use the full power of Sitefinity. However, I maintain that updated documentation would greatly reduce their workload and the number of duplicate questions they get. The forums are wonderful, but forums are no substitute for having good documentation in the first place.

I know that Sitefinity 4 is in development and will soon be released for beta testing. I also hear that it’s a major rewrite of a lot of core functionality. I hope and pray that they have been writing documentation as they lock off major modules and classes, because as much as I like Sitefinity, I don’t know if I want to pick up the new system through forum posts.