[image by elvez40, flickr artist](http://www.flickr.com/photos/elvez40/)
image by elvez40, flickr artist

… they say you have to know where you’ve been.

i say, to get where you’re going — you have to know where you’re going.

stupid, right? or is it?

whenever you start some sort of new venture, you have to know what the end state is. you have to set some sort of goal. otherwise, when do you know that you’ve gotten to where you want to be? when do you call it quits and move on to the next challenge?

i think one of the worst feelings in the world is when you’re churning away at something, tirelessly working, staying up night after night obsessing about how to perfect your work, and then one day asking yourself the question, where am i going with this?

some colleagues and i were talking about version control recently. in development terms, a product is usually given a dot-notation, integer-based version number. v1.0 is generally identified as the first time you ‘go live’. this of course is not 100% solid; take, for instance, public betas and other test releases (you’ll also find RC — release candidate — versions in the wild). but what’s the difference between going from v1.0 to v1.1 — or — from v1.0 to v2.0? again speaking in generalities, a major change in functionality is usually denoted as a new version (i.e. v2.0) whereas enhancements to existing functionality or bug fixes are some form of dot-notation (i.e. v1.1 or v1.0.1).

but where does it end?

what’s the end state of your software, or your document, or your ms excel data model? do you stop at 3.0? at 4.0? at 4.0.23? beyond that? this is my point. when you talk about versions of something, it’s nice to say, “well we rolled out version 2.6 and we’ve started development on 2.7.” it’s good for team morale. it certainly keeps the client happy (at least for a while) — but that doesn’t mean that you shouldn’t have an exit strategy. you ought to be building towards something; towards some kind of goal.

this is especially dangerous in agile or “spiral” development where requirements are made up on the go. “we’re done when we get everything into the system” is a horrible way to approach things. no one wants to be told that they could potentially be paying for something until the cows come home. there should be something that your system, document, etc. resembles in its finished state. take that vision, make it your goal, and turn it into your mission.

what about your career? what does sarah 2.0 look like? for that matter, what does sarah 3.0 look like? when do you reach a new plateau and change direction to work on the next mountain?

to get where you’re going, you have to know where you’re going —otherwise, you’re just spinning your wheels.