Repairing a car's engine while it's running

By Serdar Yegulalp | 2015/08/30 08:56

As soon as MeTal got to the point where I could edit and save posts, I started using it for -- well, I don't want to say production work, but I did start using it as much as I could to generate pages in some form. This was part of my testing methodology: if I run into things that break or feel uncomfortable while trying to use the product, I want that to happen as soon as possible. By the time MeTal was able to build pages, I already had the vast majority of the kinks in the front end worked out.

Now we've reached a point where we can build sites with MeTal, albeit very simple ones, because the toolset is only so advanced. That right there is its own development experience, because each time I try to do something that I'd expect to be able to do in a production system and I can't, I have to add it. Or, at the very least, make a note that this is missing and needs to go in before I can do all these other things.

Things get dangerous when you start using any evolving codebase as the launchpad for actual production work. A friend of mine once described the process of rewriting a novel a "repairing a car's engine while it's running", and being an SF&F novelist myself I totally agree with the reality suggested by that image. The same applies to what I'm trying to do here: create something I can use to do minimal production work, while at the same time building it out.

The tools available to programmers today make this a lot easier than it used to be. Version control alone is a major godsend; most everyone who writes more than shell scripts (and perhaps even that, too) should get up to speed with a version control system of some kind, no matter what language or environment they use. But beyond a certain point, this stuff stops becoming the provision of the toolset and starts becoming the responsibility of the developer. It's up to her to not try to do too many daring (read: foolish) things at once.

The problem is further complicated by the dataset used by the program itself. With MeTal, the templates used by the blogging engine, and the databases of posts, have to be saved and tracked separately. I wrote scripts to dump them all out to .JSON files and slurp them back in as a way to stay on top of that (also as a way to help move configurations between installations), especially since MeTal is supposed to be database-agnostic. Most of the testing has been done with SQLite for the sake of expediency, but I intend to make sure the whole thing works on MySQL just as transparently -- and maybe PostgreSQL as well -- before declaring it shippable.

You never realize how many moving parts there are in the engine until you lift the hood and get grease on your hands.

Tags: architecture

comments powered by Disqus