Russ Miles: 'Commit' like your life depends on it

By Caitrin McCullough

Another blog entry from Head First Software Development author Russ Miles. Enjoy!

No, contrary to how the title of this post sounds, we're not talking about life long commitment to your partner here (although that can be fun and challenging too, no doubt). Today I'm going to delve into a little lesson I learned a while back that will keep you in good stead as you carve out a career in software development.

It all starts with...

"Are you sure?" *

Three small words, but enough to strike panic and fear into the hearts of a software development. Especially when you're being asked these questions by your team lead just before you commit your code to the core codebase for the first time.

Your mind races, and you think through every step, every change that you've made between checking your code out of version control to the present moment. Have you done anything wrong? Have you missed something? Have you, gasp, broken anything that was fine beforehand?!

So you run through all those practices you picked up n Head First Software Development to make sure you've covered all the bases. You run the unit tests, you add some extra ones (after all, now the boss is actually watching you'd better make it perfect). Build, execute, re-test and test again, and finally you're feeling convinced that everything is ok.

You turn back to your boss, confident this time, you hit the button to commit your changes so that now the master copy of the code has all your code added right in for everyone to use. But then you watch the eruptions amongst the other developers...

"Whoa! Who broke the build?!"
"Wait a second, all I did was an updated and now things are screwed!"

And various other less politically correct exclamations.

You gulp down a knot of cold fear, and exit to the cloakroom to hide your shame and to prepare your resume...

That all might be a bit dramatic, but it's a real lesson nonetheless. So how could this all have been avoided? Well, it turns out that there are a couple of lessons to learn here, but it all leads up to the same principle.

First up, you really should have built in tests that made you confident in your code kin the first place. I mean, test like your boss is looking over your shoulder every time you code. That would have saved some time in the re-test loop after being put on the spot by your boss.

Second, and a sneaky point that catches loads of people out, you didn't do an update of your own codebase before committing your changes. Why is that a problem? Take a look at this little cooking analogy:

"Chef 1 takes a mixing bowl and decides that this meal is going to be a trifle, so he adds on some fruit and some glaze along with a bunch of other thing to make the base of the trifle. Meanwhile, Chef 2 has decided that the meal is going to be a Shepherds pie (full of minced meat and potato, a great English dish) and so takes the mixing bowl and adds a layer of mince. Chef 1 then commits his trifle to the serving shelf, all set to be taken to the paying customers. The Chef 2, not thinking to check the meal that is currently on the serving shelf (currently the trifle base), adds his bits to the serving shelf as well. The serving shelf, knowing that only one meal is ordered, unceremoniously mixes the two meals together! This carries on for a few more rounds until what you have is a trifle/mince meat and gravy mess that could well upset your customers, if not poison them."

Ok, so the analogy gets a bit thin when the serving shelf gets involved, but this is exactly what your code repository attempts to do when you check in changes. The repository doesn't know what version of the code you had locally and were working too, and chances are it may differ from the master copy that is checked into the repository just prior to you doing your commit, all the repository knows is what it currently has and the list of changes that you want to make.

However, this all could have been avoided if the second chef had checked what was on the serving shelf before he added the Shepherds pie changes. Getting back to code, if you'd checked out the latest updates from the repository in the earlier scenario, just before you did your commit, you could run your tests against a true representation of what was going to end up in the repository and caught any problems right up front. It's a simple rule, update and re-test before you commit otherwise you really can't be sure that your code changes will work with the current code in the repository.

It might sound like a "duh!" kind of point, but you would be surprised how many developers completely forget to make sure they have the absolute latest code from the repository before committing their changes. Unfortunately, this means that any testing you do before your commit is dangerously wasted.

So, next time you're about to commit your latest coding masterpiece, just do a quick update from the repository and re-run all your tests. That way, you can commit like your life depended on it. Doing a simple update and re-test saves a lot of embarrassment and, most importantly, helps you stay confident in your code.

* Special thanks to Tim Smart for being just that team lead that asked me that question, and taught me an extremely valuable lesson.

 

 

Comments

---

 

Post a comment:

Name

Website

Save?

Email Address (required)

Comments