DaedTech

Stories about Software

Aug
14

By

Things Everyone Forgets Before Committing Code

Category: The Life of a Programmer Tags: , | 2 Comments

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look around at some of the other posts as well.

Committing code involves, in a dramatic sense, two universes colliding.  Firstly, you have the universe of your own work and metaphorical workbench.  You’ve worked for some amount of time on your code, hopefully in a state of flow.  And secondly, you have the universe of the team’s communal work product.  And so when you commit, you force these universes together by foisting your recent work on the team.

In bygone years, this created far more heartburn for the average team than it does today.  Barbaric as it may seem, I can actually remember a time when some professional software developers didn’t use source control.  A “commit” thus involved literally overwriting a file on a shared drive, obliterating all trace of the previous version.  (Sometimes, you might create a backup copy of the folder).  Here, your universe actually kind of ate the team’s communal universe.

More Frequent Commits, Fewer Problems

But, even in the earliest days of my career, lack of source control represented sloppy process.  I remember installing the practice in situations that lacked it.  But even with source control in place, people tended to go off and code in their own world for weeks or even months during feature development.  Only when release time neared did they start to have what the industry affectionately calls “merge parties,” wherein the team would spend days or weeks sorting out all of the instances where their changes trampled one another’s.

In the interceding years, the industry has learned the wisdom of continuous integration (CI).  CI builds on the premise, “if it hurts, do it more,” by encouraging frequent, lower stakes commits.  These days, most teams commit on the order of hours, rather than weeks or months.  This significantly lowers the onerousness of universes colliding.

But it doesn’t eliminate the problem altogether, even in teams that live the CI dream.  No matter how frequently you do it and how sophisticated the workflows around modern source control, you still have the basic problem of putting your stuff into the team’s universe.  And this comes with the metaphorical risk of leaving your tools laying around where someone can trip over them.

So today, let’s take a look at some of the most common things everyone forgets before committing code.  And, for the purposes of the post, I’ll remain source control agnostic, with the parlance “commit” meaning generally to sync your files with the team’s.

Read More

Aug
2

By

Is Your Source Control Usage Conducive to Code Review?

Category: Language Agnostic Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.  Head over to their site and check out the original.  While you’re there, have a look around at posts by some other authors as well.

I can think back to times in my career that the source control that I was using (or not using) made me a cranky, unhappy human being.  Years and years ago, there was the time that a coworker accidentally left all of the files in the codebase checked out through Visual SourceSafe and went on vacation.  I distinctly remember enlisting a sysadmin and the two of us going into the source control server with admin credentials and hacking at settings until we could undo that and I could work.  You see, Visual SourceSafe employed a pessimistic locking strategy by which his checkout meant I couldn’t do anything with the code.

There was also the time, a few years later, when I was suffering through a project that used Rational Clear Case.  On a normal day, delivering code to the official branch or stream or whatever took half an hour.  If I had to work from home, it took all morning.

Angry guy smshing computer

And then there was the time that I was switched onto a project with no source control at all.  The C source code was stored on a production server — a production server that controlled physical machinery in the real world.  To “check things in,” you would modify the C code, turn off the physical machine, load the modified kernel modules, turn the machine on, and then revert real quick if things started blowing up.  I’m not kidding.  This was the commit/rollback strategy when I arrived (I did actually migrate this).

Tools Affect Behavior

These things make for fun war stories, but they also serve to illustrate how source control dictates behavior.  With Visual SourceSafe, we implemented some kind of out of band email protocol to remind people to check in.  With Rational Clear Case, I implemented a homegrown SVN for day to day version control and delivered/integrated only a few times per month.  With the machine server, there was extensive historical commenting in every single source file.  These tools spur you toward behaviors, and, in these cases, toward wasteful or bad behaviors.

For the examples I listed, I was steered toward useless process, steered away from continuous integration, and steered toward neurotic documentation.  But the steering can apply to almost anything, and that includes having a healthy code review process.

There have been studies conducted that demonstrate the importance of code review.  It is uniquely effective when it comes to catching defects earlier than later, and it promotes collective code ownership, thus reducing “bus factor.”  I could go on, but let’s take it as axiomatic in this post that you want to do it.

Does your source control situation make it easy for you to conduct code reviews?  Or does it discourage you, making life tough if you do them, and thus making you less likely to do them.  If it’s the latter, that’s not a good situation.

Read More