I’m not joking, although I’m sure that’s the first impression from this post’s title. But there’s a crucial caveat: everybody should write their own JavaScript framework or content management system; but very few should ever let their tool get used.

There’s an enormous learning value in programming a large, complex system. You get a strong sense of accomplishment, while learning just how complicated it is to create a flexible theming system, menu structuring tool, and content editor – let alone making it extendable. Writing something of that scope is absolutely worthwhile.

Having done so, however, you should probably throw the whole thing away.

(Or keep it in storage to look at, nostalgically, once you know better.)

I did write my own content management system when I was learning PHP (Hypertext PreProcessing). I learned a ton in the process. Some of what I learned, I learned just a little bit later than it would really have been valuable, which wasn’t a comfortable experience.

I definitely wish I’d known the second half of my own statement, above, before I deployed it!

But I don’t regret writing it at all.

Lessons Learned

I learned how hard it is to create an image uploading experience that was reliable, easy, and still encouraged best practice accessibility in providing alt attributes. I learned how difficult it can be to effectively handle character encoding, even when you’re installing in a known environment, once users get involved.

I learned how easily you can make a security error that badly compromises your client’s web site – although thankfully, never with any lasting damage.

That’s a lesson worth learning before deploying your content management system.

What to do with your knowledge

I’m not saying that offloading the responsibility for your content management system to a third party is a 100% guaranteed solution. Other people can also make mistakes on usability, security, flexibility, and accessibility. In fact, it’s almost a certainty. But when you’re using a tool that’s the shared responsibility of hundreds, thousands, or millions of people, you also gain the support of those people’s experiences and knowledge.

If you get involved with the project yourself, you can help shape it’s future, without bearing the entire weight of the responsibility for that project.

That’s why I contribute to WordPress. I believe that having input into the content management system you’re going to use is crucial if it’s going to continue to develop as the CMS (Content Management System) you want and need.

Having a CMS that does exactly what you need is one of the reasons for building your own in the first place. Over time, that’s unmaintainable, however. Every feature you build requires new code and new maintenance; at some point, the time spent maintaining the code exceeds your ability to add anything new – and you no longer have a custom CMS that does everything you want.

Sharing in the larger vision of an open source project means making compromises, and some aspects of the CMS may not work exactly the way you want them to. I can live with this when I know the reasoning involved more easily than I can when I’m not aware of the discussions leading to that decision. Sometimes, once you’ve discussed an issue, it becomes evident that the goal you have in mind isn’t feasible; or it isn’t in line with the projects overall goals.

Overall, the experience of building a CMS is incredibly valuable for a developer when it comes to understanding the structure of their environment and the complexities of web platforms. These skills, in turn, will benefit you when you build sites on other platforms or contribute to large open source platforms.

But it’s pretty unlikely that the CMS you built should ever be used by anyone, anywhere.