I’m 13 years in, trying to build a blog that will last my entire life. I’d like to share what I’ve learned about thinking and coding for the long term.

In late 1999, I was 14 years old, and had just spent the last few months absorbing TI BASIC and trying to grok Z80 assembly. Seeking a community of like-minded individuals, and lacking the wide net or social aspirations to find one locally, I was also hard at work assembling an archive of TI Calculator software using free web site hosts like Angelfire and Tripod. I won’t link the results because, wow, are they embarrassing.

It was a thrill to write words and code that everyone in the world could see and use. So, one day at the end of the summer of 1999, I thought: “I could write about myself somewhere online. A page about me.” I posted this picture:

and some accompanying text. Ever since, I’ve had a personal website. It never occurred to me to throw it all away and start over, so I carried the few posts I made at each site forward. After the free-hosting sites, I was very generously hosted at a place where I cobbled together some Perl scripts to make a rudimentary blogging platform. It was about this time that I realized that, no mater how dull, I wanted to record my thoughts, feelings, opinions, and interests for the rest of my life. Sorted, archived, tagged, navel-gazing, I suppose.

I wanted to make a journal that would exist for the rest of my life. An online journal that could make it to 80 years old.

Since then, that thinking has shaped the entire project. I’d design, and then tear it all down. Re-code, re-design, tear it all down. I’ve long since lost track of the iteration count. Nothing felt maintainable enough. It was all rickety, immediately crufty, spaghetti code. I was two things: (1) young and (2) an amateur. This was not a great combination for writing long-lasting software.

Then, before dental school began, I had a job where almost nothing was expected of me. I used the work-weeks to my advantage: I buckled down and wrote an object-oriented and markup agnostic publishing program in PHP. I named it Pax. I didn’t know about this PaX. I know, I know… PHP. I selected the language I had spent the most time with, which, for any amateur with my history and from my generation is nearly always PHP.

But, in the face of the challenge of the 80 year goal, I began to realize that I wasn’t thinking like a lot of other coders. Keep in mind the following points may not be true for you—your project has different goals than my own. However, these are the little epiphanies I have had while attempting to make this project live and breathe for a long time.

(0) “Good enough” isn’t good enough.
Every time, every SINGLE time I have stopped coding something when I had it working, instead of pushing, refining, rethinking, refactoring it until I KNEW in my gut it was right, I have regretted it. I’ll come back after a year, seeking to tweak something, only to realize “oh crap, I stopped short of what I should’ve written then.” Maybe it is something as simple as this: my text processing object can be instantiated with an array, but not all methods properly work with arrays. That’s just really poor practice, I know, but when you’re coding along and you say “TODO:”, you’ll get distracted adding the next exciting feature.

Yes, those functions returns should be more consistent.
Yes, make that behavior configurable.
Yes, your documentation should be crystal clear… or even better, the code logic and variable names should work together so you can quickly scan old code and understand what is happening.

I learned, at a visceral level, that when you understand the code, when you have that entire mental model of it in your head, that is the time to refine and get everything right. You think there’s no way, after wrestling with some logic for weeks, you could ever forget all of the intricacies, but you do. If you do all your work before you forget, you get to blackbox those classes in the future.

(1) If you work atop someone else’s code, you get someone else’s problems.
Look, someone else’s problems might be minimal! They may understand how to tackle this problem much better than you have the time for. And really, frameworks like CakePHP are great… until they aren’t. At that point, do you delve into the code to add the feature you need? Beg the developers? Paste an ugly kludge layer on top of the clean model? Abandon the framework/library and rewrite?

So, I tried to avoid blogging platforms and PHP frameworks as much as I could. This is what made me evade the ubiquitous Wordpress, the excellent Movable Type, or the (slightly) arcane Drupal. Heck, trying to keep a version of PHP on a server running for decades is going to be hard enough… and I’m resigned to the fact that I’ll have to port, rewrite, move servers. (How I’m going to do this when I’ve spent years in a different career, I don’t know. I’m only 13 years into this, after all.)

Here’s the thing: those blogging options I mentioned are generally quite nice, and were written to help people rapidly develop websites. But none of them advertises “we’ll power your site for 80 years!” I guess my parameters are different.

I’ve realized spending my time configuring platforms whose existence I can’t even count on 10 years in the future is a bad use of my time. It may not be a bad use of your time, for your project, but it is a bad use of my time.
By contrast, spending my time learning how to write (simple) software (along with the bonus of understanding it better) is a good use of my time.

The one problem here is how you define “framework”—perhaps you’ve decided you don’t want the abstraction of CakePHP; but consider that you are still using the “framework” of PHP running on the “framework” of an x86 *nix OS… where do you draw the line? I’m just looking to _minimize_ the number of layers I build up. At some point, over longer time scales, the difficulty with maintaining yet another layer of abstraction outweighs the benefits. You still need layers, just within reason.

Minimizing these layers aids understanding, which brings me to the next point…

(2) If I don’t deeply understand it, I can’t maintain it.
Here’s an example: I wanted to completely abstract the HTML out of my PHP. In the future, if I wanted to output my site in an as-yet non-existent markup language, or LaTeX, or God-knows-what, I’d have a place to start (rather than trying to rip out antiquated markup). Sure, I could’ve used any one of the PHP templating implementations out there. But what happens 8 years from now, when changes to PHP break the templater, I’m a busy father, and the team that supports the template engine has long since disbanded?

I’m screwed, that’s what happens!

I’d have to downgrade my site to spitting out database info directly… and while Markdown is nice, I’d prefer not to subject my future readers to reading it directly.

So, I wrote my own template “engine”. It was great regex practice, and the result is extremely small and simple. I can maintain it. After all, arrays and regular expressions likely aren’t going anywhere anytime soon.

(3) Focusing on maintainability prevents feature-bloat.
First, I pared my project down to its essence: it’s a list of thoughts and images of my life, in reverse chronological order. It is not about sharing buttons. It is not about the newest or coolest. The core purpose of my software is to deliver to the user a reverse-chronological list of data. Thus, I spend most of my development time making existing features more robust and ensuring that adding my thoughts and/or photos is as painless as possible.

That’s it.

Wouldn’t it be cool I thought, to have Javascript-powered browser-side cropping of photos? But, you know what wouldn’t be cool? When that breaks in the future. My methods may not be a good way for most folks to prevent feature bloat, but adopting the longer-term mindset when implementing new ideas and features is a nice counterpoint to the bleeding edge.

(4) Thinking long-term is a fun challenge.
Historically, I tended to distract myself by attempting to bolt on features of questionable value to my homegrown platform. Now, instead, I consider other problems. For example, I store my mySQL dates in a timestamp column. I like this option because it lets me store in UTC, and output in whatever time zone I’d like. In 2038, however, this method will no longer work (32 bit overflow, blah blah). An example of the thinking (from that Stack Overflow link):

Most real world PHP applications will not still be around when 2038 rolls around as the web is not really a legacy platform.

I’m not sure what “real world” applications are (this implies there are “fake world” applications), but 2038 is not far away when your software does mortgage calculations. I’m glad mine does not.

(5) Be ready to move. Now.
I recently got an email from my host, Joyent, that my account would soon be discontinued and everything would be deleted… in about 60 days. I most certainly was not one of the VC round promised ‘lifetime’ hosting. I just bought an Accelerator from them, paid yearly, and they phased it out.

I’m not upset, I expected this, and thinking long-term helped. Back-up scripts run 4 times per day, local copies of database and config files are all here, I’m ready to go.

I think this nomadic thinking applies to keeping anything vital and functioning in the computer world. Expect and prepare: the hard drive will crash, the service will end, your data will require exporting, and updates will be filled with breaking changes.

At this point, 80 year software isn’t real, but it is a frame of mind.

• Tumbledry
• Coding
• Future
• mySQL
• PHP
• Alex Micek

4 comments left

Essays Nearby

• Vacationing
• Playfulness and Ive
• Bertrand Russell on Teaching
• 5 Things About Television