We all have those personal learning projects that inspire pride in us. Many are our own takes on existing frameworks and tools such as content management systems, math libraries, billing systems, layout frameworks, game engines, etc. Attempting such projects is a vital part of learning to code, picking up new languages or approaching new ways of thinking. I’d be remiss not to encourage people to take on such tasks as a method of improving their skills and a liar if I said I hadn’t done it hundreds of times over myself.
But for all the neat features we include and despite how proud we may be of our work, we need to seriously think twice before using these projects as production systems. Below I’ll detail the top reasons why you should be wary about letting your hobby project suddenly become the linchpin of a commercial or enterprise application.
TL;DR
Established projects can have hundreds of contributors working on it for tens of thousands of dev-hours.
One programmer working alone won’t have the breadth of experience in every facet of development nor the depth of knowledge in each particular domain that large-scale group projects encapsulate.
Security
Everyone scorns Wordpress as being insecure, but in all honesty the team of developers behind it is incredibly responsive at fixing any security holes. Most of the hacks come from ancient installs which are easily targeted by vulnerabilities which should have long been patched or plugins which aren’t held to the same scrutiny as the WordPress core codebase.
What makes WordPress more secure than a CMS you might be working on? As their security page discusses, they have a dedicated security team containing around 50 people with expertise in web application security. They have a greater wealth of experience available to detect issues, respond, and patch then single-person projects and that’s just their security team.
Compatibility
Linux is the most well-known open source operating system kernel available today and it runs on practically everything. It powers every Android phone in existence, most of the web servers in the web, it runs Smart TVs and routers, in-car media systems, all but two of the top 500 supercomputers.
However one of the problems of writing anything - from an operating system to a web page - is getting it to work on more than just your machine. A classic example is building web pages with CSS. The task is a nightmares to even experienced web developers who can spend days making sure it works on their Chrome desktop, Android tablet, and Windows smartphone only to discover it refuses to load at all on iOS devices. This is why we have frameworks like Bootstrap and Foundation who have put hundreds or thousands of collective hours into creating frameworks that work not just on modern devices but even ensure compatibility with users who might be a bit behind the curve.
Sure, something might work on your flash new Macbook Pro when you’re on a fibre connection with 0ms latency to the server it’s running on, but what about users on the other side of the world on DSL or (heaven forbid) satellite connections? What if they don’t have the money to justify upgrading their Windows XP computer or haven’t heard of Chrome or are stuck on a work computer where they can’t install software? Having a large community work on software allows more chances to test it on all kinds of systems.
Edge Cases
When coding it can be tempting to assume that the ISO year starts on the 1st of January. Or that people have at least two names.
That isn’t the limit for edge cases though. I recommend visiting Your Calendrical Fallacy Is before deciding to handle any dates or times yourself, look up Thomas Burette’s blog post on CSV handling, and check Patrick McKenzie’s blog post before deciding to handle names yourself. There’s a great look into modeling marriage in SQL too. Each of these helps break down some common preconceptions that we might have. The privilege of having a name that can be expressed in ASCII or not worrying about DST can blind us to the plight that other users might have, that can prevent them from using systems or worse, misrepresent them and cause them difficulties later on (you can’t tell but I’m glaring pointedly at my bank who removed the apostrophe from my name).
This is why we resort to knowledge amassed as a society, to using standard libraries or importing frameworks built by specialists in those areas.
Maintenance
This last point should be brief and it heavily dovetails with Compatibility and Security from before. Let’s say you decide to use your CMS at work and then 10 years later you leave. Who will maintain it or add new features now? What happens if they have to upgrade the operating system, web server, or database for security reasons and it’s no longer compatible?
What happens if a critical flaw is discovered in a script you wrote that manages industrial control systems at work? Sure they can page you and you can grumble a bit and fix it but the same thing might happen if you’re on vacation or worse, have become an ex-parrot?
Don’t stop experimenting!
With all this said, I implore you to keep building and exploring and experimenting. Just because your kernel might not be as secure as OpenBSD or run on as many platforms as the Unity game engine doesn’t mean you should drop it. Learning through building is an important part of a software development journey. Who knows, you might open source it and have other contributors help patch bugs and add features and be the next Apache?