Over the last couple months I've been hearing the term "Technical Debt" get thrown around frequently, describing the effect that results when decisions are made in a project or process that cause problems down the line.
As any good developer will tell you, there are usually more than one way to solve the problem. Once you've narrowed down your options to a few viable courses of action, it's usually the fastest or cheapest that gets chosen. I'm not here to say this is an incorrect way to choose between good options, but I'd say that when we're planning the development of a project, or even just a feature, we ought to also say to ourselves, "Which approach will leave us with the least technical debt?"
The problem is that this isn't an easy question to answer, because we don't always know what new technology, approach, service, or totally different alternative is coming down the road. So what seems like the best idea today may be what we lose sleep over a year from now. What are our options, then?
After jumbling it around in my head and thinking through some of the real-life examples I encounter in my every day work, I think the best answer is to consider which is the most flexible approach. Which solution ties us down the least? Which method is the easiest to rip out, expand, convert, or replace at a later date? What does approach A prohibit that approach B does not? What technologies or methodologies are we committing to by choosing one option over another?
I don't think that I'd go so far as to assert that the most flexible option is always the best, but rather I'd stress that giving flexibility heavy consideration in the decision process is warranted... because you may be paying out the time and/or money later to the Technical Debt accrued by your decisions.