Writing

Software, technology, sysadmin war stories, and more. Feed
Saturday, September 14, 2013

Would your code work after a trip back in time?

I recently had an idea for one more thing to consider when choosing how to build a complicated software project. There are the usual concerns about money and time and programmer ability and all of this. I'm talking about something unusual here. It's a deceptively deep question that the stakeholder should ask the programmer who is ready to launch into building this new thing.

Would the program still work if you sent the source code back in time 10 years?

Let's look at some of the answers.

The first one is "yes", given quickly. Either they didn't think about it, or they have already thought about it in advance and know for sure. The person who answers without thinking about it is probably going to give you other problems down the road. The one who has already considered this is "on your wavelength", so to speak.

Another answer would be "yes", after a considerable delay. I assume this wouldn't happen too much since it would make for an awkward silence as the programmer pondered it on the spot. I think it would be more likely to hear something else instead.

What about "I'm not sure" or "maybe", possibly after some small amount of silence? That seems like a much more reasonable place to start. Who's really going to know this sort of thing in advance, anyway?

A "no" given quickly might reflect "shinything" syndrome on the part of the programmer. They have probably made a conscious decision to use the very latest version of everything, and their programming language or framework flat out did not exist back in 2003. They know this and so are proud to answer quickly. They like being on the bleeding edge.

The goal is to get to a place where you start talking about nuts and bolts. No matter what the initial answer is, you start using it to dissect the project. Maybe the programming language did not exist in 2003, or did not exist in any usable form. That's good to know. Maybe it relies on some libraries which did not exist, or if they did, some newer feature of them hadn't been written yet. Then you get to talk about those features and what sort of workarounds you'd have to do after a trip back in time with this code.

It's basically a sneaky way to start exposing dependencies. It's also like nerd candy, because, come on, time travel, right? Sending code back in time? They'll be so caught up in that fantasy that they won't realize you're asking high-level risk assessment questions in the present.

So okay, what's my point in even asking this? Easy. I'm looking for ways to see how fragile something might be. Sure, it'll probably work on the one machine the programmer configures "just so", but how well will it work on the server-class machine with a different flavor of Linux? Server type installs tend to lag behind desktop level stuff in terms of features and versions, after all.

How about finding other people to work on the project? Is it using some language that nobody's going to know yet because it was only invented in 2010? Are there only 10 people on the planet who know how to be useful in this language or framework yet? Are you prepared to pay for one of them to replace your programmer when that person moves on to the next shiny job?

There's also the matter of whether something is common or not. Will you have to do a special install of some runtime environment or library on all of your servers to support this thing, or is it already there? Don't laugh - this has happened with Ruby, Python, and Java to name just three. For years, various Unix flavors came without one or more of those things installed until market forces finally forced the OS vendors to provide a solid way to have them installed.

Until that happened, you had to do it yourself. That's one more thing to worry about and maintain apart from the usual vendor-supplied updates.

Some of this is an underhanded way to see just how much your programmer knows about what's really going on under the hood. If they say something like "we'd probably have to disable ECN since a bunch of firewalls still thought those were evil packets 10 years ago", that suggests a decent amount of domain knowledge. It's also a good chance that if you happen to trip over a customer site which still uses one of those dinosaur firewalls with the ECN-hating rulesets, this person will find it and know what to do about it.

I imagine this kind of question will lose most of its effectiveness if it takes off. It's just like the "round manhole cover" question. At some point it was fresh, but now it's well-known and worn out.

I hope this one turns out to be useful and has a nice run.

10 years is an arbitrary value meant to purposely be too long. It's deliberately far enough out to expose a whole bunch of things which really should not matter any more. The problem is that if you stick to something less, you might not get people to use the kind of wide-ranging thinking that you need to get the whole picture.

So, ask about 10 year compatibility... but maybe insist on less.