Blog Invented Here
Build or buy? Buy or build? I chose “build.”
Welcome to the Blog
Let’s talk about the obvious answer: I wrote the blogging engine myself. That’s like Newbie Programming Mistake #1. There are dozens—hundreds!—of pre-built blogging tools out there. Everybody’s made one, and some of them are actually really good. Any of them could have got me up and running quickly. And yet, when confronted with the decision to buy or build, I chose to build. And here, finally, a year later, a blog. Hmm.
Is it a character flaw? Do I suffer from an extreme form of Not Invented Here (NIH) syndrome? If you’ve been watching the show for a while, you know that I have my grievances with third-party code. Perhaps I took it too far.
Exactly What Kind of Idiot Am I?
You would have to be a monumental idiot to build everything yourself. To misquote Carl Sagan, if you wish to build a blog from scratch, you must first open a silicon refinery. I’m not that kind of idiot.
At what point does a pathological NIH-er such as myself stop reinventing the wheel and start relying on other people’s work? Given the paucity of silicon refineries dotting the landscape, it must happen sometime. Where? And why?
The Limits of Reuse
Let’s look at the other end first. Why would anyone ever not reuse an existing tool or service? Expense is one possibility, but free blogging engines abound. Another possibility is lack of sophistication or quality, but again, there are good tools available that will do just about anything you want.
No, for me, the issue wasn’t the options available. Sure, third-party tools are often poorly documented. Sure, they can have surprising limits. Sure, there’s bugs. I’m okay with that. My code isn’t perfect, either.
The difference is that my code is under my control (or our control, when working as part of a team). It does what exactly what I want, in exactly the way I want it to. And when my needs change, as they always, always, do… I can change my code, just like that. No worries about whether my request for help will be acknowledged. No need to study the code, submit a patch, and have it ignored for 30 days before being rejected. No need to keep up with the latest releases. No worries that a crucial API I depend on will be deprecated, or that a critical service will change its business model and abandon me as a customer. Changes happen on my schedule, according to my needs, not the whims of my vendors.
Fantasy? Paranoia? Far from it. Here’s a real-world example that’s a bit too close to home:
My Art of Agile blog has ten years of blog entries in it. It collected thousands of insightful comments over its run, especially on seminal essays such as The Decline and Fall of Agile and Alternatives to Acceptance Testing.
Don’t bother going to the site to read those comments, though. You can’t. The popular service I used decided to focus on social media instead. They discontinued all support for the tool I was using. I still have the comments backed up, but they’re locked away in an XML file.
Of course, none of these reasons are worth a whole year of delay. Why not just use a third-party blogging service in the meantime, then switch over when mine was ready?
There’s Nothing So Permanent as a Temporary Solution
There’s always something new demanding your attention. In my experience, once a problem is solved, even if it isn’t solved well, the urgency to continue working on it dies. Worse, a temporary solution tends to receive less effort than it needs, because “it’s only temporary.” It’s hacked in, then as changes are needed, hack accumulates on hack. You end up spending way more effort than anticipated, because your “temporary” solution was never designed with maintainability in mind.
Years later, you look back at your accreted pile of sh…tuff and realize that replacing it is going to take major effort. And you have to replace it, because you’ve been dancing at the whims of its breakages and upgrade-induced incompatibilities for too long.
Instead, I evaluate every solution as if it were a permanent solution. If I’m going to continue supporting a solution for the conceivable life of my site (years to decades; I treat URLs seriously), what kind of effort am I setting myself up for? What maintenance will I have to perform, when, and why?
From this perspective, the cost of a third-party blogging service seems pretty high. I want to integrate my blog throughout my site. How hard will that be, and how can I ensure it doesn’t break? I want to continue to modify and upgrade my site as technology fashions change. Will I be able to do that? I need my blog to stay alive with near-zero maintenance costs, if necessary, for years to decades. Is there any service that I can rely on for that sort of longevity, that won’t require me to do an emergency replacement when my focus has moved on to other things?
Still, is this all really worth a year of effort? Definitely not.
The False Premise
The blog didn’t take me a year of effort. It’s been a year since I launched the site, but I only started working on the blog a week and half ago. It took 34½ hours of programming effort. (I track these things.) It’s been a year because I put other priorities first.
Now the equation makes a bit more sense. Thirty-five hours of effort to ensure that I choose when and how my blog changes? Sold!
Of course, there’s a million things those third-party services do that mine doesn’t. Some I don’t care about: I have to write my entries in a text editor rather than in a fancy WYSYWIG interface; I check my files into Git rather than uploading them to a database. Others matter more, and you may have already noticed their lack. (Tell me what you want in the comments. It’ll help me prioritize.)
All-in-all, I feel like this was the right decision given my circumstances.
Where’s the Boundary?
Okay, back to the question. At what point does a pathological—or perhaps, just sensible—NIH-er stop reinventing the wheel and start relying on other people’s work?
For me, the answer comes down to maintenance costs. It always comes down to maintenance costs. When something needs changing, I either spend my precious and incredibly limited time to fix it, or I turn it off. So: what can I safely reuse, and what do I build myself?
Here’s how I answered that question for this blog.
For the blog pages and content management? Build. A good blog integrates with and augments your entire site. That sort of customization is harder to do with third-party tools. A blog also provides content that people will refer to for years. I don’t expect third-party tools to last that long. And because this site runs on a home-grown content-management system, most of the work involved refactorings and refinements I wanted to do anyway. Cost: 31¾ hours.
For the Markdown rendering engine? Buy. Once integrated, it doesn’t need changing. It’s easy to encapsulate for later replacement, and I wrote enough tests to be confident that any future replacement will work the way I need it to. If I end up dissatisfied with Markdown, I can start using a different tool entirely without needing to replace existing blog entries. Cost: 1½ hours.
For the comment engine? Buy. This is the most risky decision. I’ve already run up against Disqus’s shortcomings—specifically, it’s really not good for posting code snippets—and I highly doubt it will be around as long as this blog is. But building a comment system, even a “barely good enough” one, is a major effort. I can’t afford to do that. In the worst case, I can simply turn off comments entirely until I have time to fix things. It’s not ideal, but I don’t see a better choice. Cost: 1¼ hours.
There are so many cool tools and frameworks out there that I expect this perspective to be unusual, even unpopular. I’m okay with that. Every decision has to be evaluated in context. If I wasn’t thinking ten years down the road, those tools and frameworks would hold a lot more appeal. But my context is different, and so my methods are different too.
After all, this blog will still be here in 10 years. Welcome!