The Importance of Development Environments

My first job as a software developer was in 1998, while I was an undergrad at the University of Arizona in Tucson, AZ.  The project was simple: build a JavaScript application to front a website that helped people incorporate a new business.  This was long before "ajax" became the new hotness, but I'd built full windowing environments in JS (supporting both NS4 and IE4) back in the mid '90s so this was old hat for me.  The client had a single environment.  Production.

This was not ideal.

My next job was after I'd dropped out of school, up in Portland, OR.  It was a small web development agency and we had a dedicated development server in our office which we worked on, and then separate production servers colocated offsite.  This was much better, but still meant we (the developers) stepped on each others toes all the time.

Getting better…

Next came working for a university on some internal project, still in Portland, OR.  I was the sole coder, and while I had my full development environment on my local machine, the most striking difference wasn't that it was local (and therefore fast and easy to screw with), but that I didn't have to compete with other devs' changes.  This was a big boon, and my productivity demonstrated it.  But still no version control, if you can believe it.  I still don't understand why that isn't forced on students in CS 101 before the first code project.

Almost there…

My first "real" job was up in Bellingham, WA with a company which sold communications management software.  The whole app was ColdFusion and sold with a SaaS model (about the same time as Salesforce.com was conceived).  There we not only had a production cluster, we had a staging environment, a dev (bleeding edge) environment, and per-developer environments on our local workstations.  It was here that I learned about version control, saw that it was a Good Thing^(tm), and put on my tantrum face and forced everything to halt until we had it implemented.  We used CVS, and then upgrade to SVN just after it went 1.0 (after watching it get closer and closer with bated breath).

We've got it!

My next job was back in good old Portland, OR.  I had to create SVN infrastructure, but no worries.  I knew what we needed, especially with six developers.  Also had to create local-workstation development environments, but again a completely worthwhile investment.  The trick was learning to leverage all of this, which brings me to the point.

Every developer should be able to blindly and without regard for any consequences thrash their working codebase to see if random idea X works.

It has taken me a decade to really appreciate how important this simple idea is.

If you can't do this with your current development environment, you should invest some time in making it possible.   It means you need to be able to break any and every piece of code without affecting anyone else.  Including yourself if you need to fix some urgent bug all of a sudden.  It means you should be able to use version control if your idea takes 75 commits to test out, without affecting anyone else.  Including yourself as before.  It means that if your idea works, you shouldn't have to struggle to share your solution and get it into the next nightly.  Even if you're the only developer.

So what do you need?  You need (at least):

1. version control which supports concurrent editing, branching and merging
2. a completely isolated instance of your software project with it's own working directory
3. the ability to create n copies of #2
4. a habit of small atomic commits (commit early, commit often)
5. the confidence in your setup to trust that no matter how bad you screw things up, you can always get back to any previous state whether it was five minutes or five months ago

The first points is a no brainer, but is vitally important as it is the only way to get the remaining four items.  Points two and three are different sides of the same thing as #3 is really just #2 where you have two personalities (normal dev and crazy hacker dude).

Point four is a learned skill.  This isn't a piece of technology you adopt or something you do, it's a habit you consciously work to build because you want to be a better developer.  It's hard.  Everyone knows it's far easier to just take a pile of changes you've made and commit them with a message like "fixed stuff".  Suppress that urge.  Don't give in to the easy road.  Spend the time to fix one thing, ensure it works, ensure it's atomic, and commit it.  Then move on to the next thing.  If you're working on eight things at once, first go talk to your boss because they're clearly insane, and then think about point three and do each task in a separate working copy (perhaps even against a separate branch).  This might seem like pure hassle and no benefit, but it's the only way to make the investment you've made with points one to three actually pay off.  Version control repositories with non-atomic commits are certainly better than no version control at all, but the non-atomicity severely hamstrings their primary objective: the ability to act as a time machine.

Which brings me to the final point.  Confidence is a learned skill.  It comes partially from trying and succeeding, but it mostly comes from trying and failing and learning that your precautions keep you safe.  It's important to pick up random idea X and give it a whirl.  Really important.  And the only way to go about it is with the confidence you can recover from anything.  Anything.  If you don't have that confidence, you're going to go about it in a half-ass manner in case something unexpected comes up.  It's human nature; don't feel embarrassed.  What you have to realize is that because we are software developers, we have a distinct advantage.  We have a time machine.  We can go back in time, to any point in time, and start over fresh.  The lack of physical deliverables gives us this advantage, and we'd be fools to not take full advantage of it.

If you can't do that today, I strongly encourage you to think about ways you can get closer.  Don't worry about trying to get there in one step, just get closer.  Do that repeatedly and you'll get there, and every step closer has tangible benefit to future development.  It is worth every ounce of energy it takes to get there.  It's also important to look at new projects with the same mindset; setting yourself (and your fellow developers) up for this from the get-go is simple if you have the forethought to do it.

I have confidence in my development environment.  It's not perfect, but I have no qualms about ripping the heart out of a 300,000 line subsystem and seeing if I can put it back together.  That confidence means I can act.  I don't have to worry about consequences until I can reasonably weigh their ROI.  No more "what ifs".  Interestingly, every Star Wars nerd's favorite line is exactly wrong when applied to software: "do or do not, there is no try" "try, there is no do or do not".