Tag Archives: thoughts

Version control practices

Thoughts on good practice when using version control, based on my experience, and not in any particular order.

Commit one “thing” at a time, where “thing” is a feature or a bug fix. Don’t commit a feature at the same time as a bug fix, or multiple bug fixes at once.

Review what you’re actually committing – the files, and their contents. You may have temporary changes to some files, you might have forgotten to deal with a FIXME, you might have used an editor that’s messed up the whitespace/indentation of entire files.

Sometimes you get called upon to fix something while you’re working on a feature, with some half-done changes in your working copy. Create a branch, switch to it, commit your half-done stuff, then switch back to trunk to fix whatever it is. When you’re done fixing, either continue your work on the branch or just merge it in to trunk straight away and carry on.

Commit messages should say what you did, and if relevant, why (e.g. what issue it fixes). Bad examples are “changed js file”, “fix bug”. If you’re working on a feature and make multiple commits, “<name of feature>” is not a good message.

Learn how to resolve conflicts properly, take care when doing it, and test after merging (even if there were no conflicts). If in doubt about a conflict, ask someone. Learn how to resolve tree conflicts properly. Use a clean working copy for merges.

Learn how to revert committed changes (reverse merge), or ressurect files with history (svn copy).

Preserve history on file moves. Use svn move, or your SVN-enabled IDE to move files. These will track the fact that the file was moved, and the history will remain linked in SVN – this is called “addition with history”. If you just use Windows Explorer, your move will become just a delete and a corresponding unrelated add.

Advertisements

Nine Things Developers Want More Than Money

Came across this good post from a while ago by Rob Walling about Nine Things Developers Want More Than Money.

A few points I noted, or reminded me of things I’ve seen:

  • Developers want to build software that they can take pride in. Management often only want them to build the minimal thing that’ll work.
  • “Being forced to build crap is one of the worst things you can do to a craftsman”, and it feels like a failure even if you do it on time
  • Developers want to learn new things and be challenged, in order to be happy.
  • We want to work on the right kind of challenges. Not, for example (my own one here), spending months trying to sort out crappy software someone else wrote.
  • We need to be listened to, and where needed actions need to be taken based on what we say. The build is slow, we need faster machines.
  • We want to build things that matter. My own example, not some obscure counter-intuitive feature that we know will never get used.
  • We don’t like being tied down by poor legacy systems we have to accommodate and work with.

Thoughts on TODOs

I’ve seen many TODO code comments in my life so far, and they’re something I think should be handled with care. From discussion, and online reading, I realise that the best way of using them will vary between people and teams.

The biggest issues in my opinion are:

  • hidden work – there is no visibility in the bug/task tracker/project plan of work that may need to be done based on a TODO
  • accidentally checked in code with TODOs next to it
Examples:
@Ignore //TODO don't check in, fix this test

catch (SomeException e) {
    //TODO do something about this
}

//TODO this whole thing will need to be reimplemented before feature x can be done

A good-sounding method I’ve heard of being used is the following (although I haven’t used it myself):

  1. developers put their name or a bug ID next to TODOs
  2. before each release, remove all TODOs – delete them if no longer applicable, or create tasks for them.
    1. Item 1. helps with this
    2. Remember to include all file types (those that your IDE might not scan by default)
    3. Also applies to FIXMEs

This goes some way to address the issues and avoid TODO-explosion in a project, while not adding too much overhead to day to day development that might discourage developers from documenting issues, improvements and so on using TODOs.

Open source to fix public sector IT

An interesting article by Mike Hadlow –¬†How to Fix Public Sector IT.

As nice as it sounds and as much as I’d like to see it happen, with the amount of existing vendor lock-in and the need to have a “blameable” party when things go wrong, I don’t see it happening even if the desire came about to do it and the focus on short term cost cutting went away.

Perhaps it would help if there was some central government open source support team that would back up departments that use OSS, somewhat like what Red Hat do with paid-for support for the OS JBoss.