Mike is currently…

getting whipped at Halo

Pragmatic Version Control Using Subversion

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages



Google

Tue, 30 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

When To Commit

I’ve been using source control since my first year at Uni, when I was doing practical lab work on my own machine. I wanted the computer to do the hard work remembering what I’d changed and when. RCS was my first attempt, but this uses your working directory to store all your revisions, and a misplaced recursive-delete knackered my mornings work. CVS worked a lot better, then at work I fell in love with Perforce, and more recently have been looking at Subversion – it really rocks. Real atomic commits, offline diff and revert, branching and tagging as directory operations, and it’s Free.

Tim Bacon gave me some interesting feedback on my entry about source control as backup. I’d mentioned that you could theoretically commit every time you’ve got a green bar, but tempered this to “significant” green bar. I wanted to note that you shouldn’t really commit every time you make a change, because your source control system will get littered with commits, possibly making future review of what has changed more difficult.

Tim’s comments prompted me to revisit why I said this. Why not commit on every green bar? Why not have an IDE that automatically commits every time you perform a refactoring? Surely organisation of changes is source control’s job, not mine. We’ve got a problem because we’re providing commits at too granular a level. We need a way to group those commits into bigger changes associated with functionality or bugfixing – these are the “significant green bars”. Perforce has a mechanism for tagging each commit with a ‘task’ to which that commit relates, a feature which can be used, for example, for bug tracking integration. This would work, as long as we could then choose granularity when browsing file history.

Something that provides a pretty good balance between the two is IntelliJ’s “local VCS” feature. It tracks your changes locally, storing several days of history, and has full integration with IntelliJ’s refactoring features. What’s more, it automatically applies labels whenever you compile, debug, run tests, etc. The actual labelling is fully configurable, and I can browse my granular changes locally, whilst committing bigger changes through my ‘official’ source control system.

Posted 13:51, 30 Sep 2003.  

Mon, 29 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Nice Guy Eddie

Most people on this planet are nice. They’re not necessarily the most friendly, have the most time on their hands, or are the most able to relate to you, but fundamentally I think they’re not so bad. We all tend to do things the best way we know how, and those methods don’t always agree between different people. The next time you’re fuming to yourself that the guy across the office from you is a total arse and probably doing things just to annoy you, consider why they’re doing what they’re doing. Let’s assume they’re not actually trying to make your life hell, just that they’re trying to do their job. You’ve reached a different conclusion from them about the best way to do something. Do they have the same information about the problem you do? Do you have all the information they have about the problem? Do you have differing experiences regarding how things have worked in the past? Put yourself in their shoes for a moment, try to think a little bit like they do, and take some time to understand each other.

This is obvious stuff, but it’s remarkably easy to forget, especially working on a software project. There’s a million different ways to do things, everyone has their own idea of what’s best and there are often arguments about how to proceed. No-one’s really out to scupper the project, though. Right?

Posted 17:32, 29 Sep 2003.  

Wed, 17 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Source Control As Backup

At lunch today I was chatting to colleagues, generally setting the world to rights, and one of the guys said, “But source control isn’t backup – you should backup your laptop anyhow.” We were discussing the problem of having a large set of changes on a particular machine, which was pertinent since my laptop decided to die on me last week.

The thing is, I do think of my source control mechanism as backup. I don’t consider a change I’ve made to be “real” until it hits source control and other people can see it. In ideal conditions I’d like to check in whenever I’d produced anything significant – I like to think this happens several times a day. So if I’m checking in every few hours, source control is indistinguishable from a backup medium. In fact, it’s better than a backup medium because I’m exercising it more often (incremental daily backup is the most frequent backup I can imagine doing).

I could take this further, couple it with TDD and say I should commit every time I’ve added a test and have a green bar. This is probably a little too much, but I’d certainly like my environment to support frequent checkins. You’ll need to fix any Infrastructure Smells first though – this doesn’t work very well if someone makes a mistake and the cost of a build breakage is high.

Posted 13:56, 17 Sep 2003.  

Mon, 08 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Developer Folklore

There’s a lot of information in developers’ heads on most projects. It’s one of the reasons that methodologies that don’t treat people as individuals tend to grate – we’re not actually interchangeable cogs in a machine, we have different strengths and weaknesses, different ways of working and interacting. Agile and XP try to help interchangeability of people through things like pairing and rotation around teams, but at the end of the day knowledge is still tied up in developers’ brains.

We jokingly used the term “developer folklore” to describe this. At the client I’m working with right now, we have around 80 developers. That’s a big project, and we were seeing problems with each team doing things slightly differently – mostly to do with IDE setup, how exactly they’d perform a build and test, etc. We have a Wiki set up as a central “hive mind” but this doesn’t quite solve the problem. How to get things working for us had become folklore, rather than an actual documented process. We’re now working on ways to make sure that knowledge is transferred a little more formally between developers.

For small teams, I don’t think this matters. In fact, it’s a good thing to have a bit of folklore, and if you’re moving fast your current state-of-the-art can change pretty rapidly. Documenting every little thing can slow you down. Paul Hammant talks about “telepathy” between developers, and that only seems to arise in small teams. You and your fellow developers become attuned to what the others are doing, and can half-explain a concept before everyone else jumps all the way to the end without further help. Developers find themselves conversing in half-finished sentences, instinctively moving together in the same direction. Telepathy is something people who’ve done pair programming will easily relate to, and I think finding it with your development team means you’re doing good work. It’s one of the things I think is most consistent with projects I’ve enjoyed in the past.

Also today my colleague Stacy Curl wrote about the Immutable Storycard Anti-Pattern. We ran into it and quite a few of the developers in the room felt instantly that something was a little screwy, without really needing to voice that opinion too loudly. Telepathy kicking in perhaps?

Posted 17:01, 08 Sep 2003.  

Mon, 01 Sep 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Restaurants in Lisbon

Had an absolutely fantastic meal a couple of nights ago at a restaurant in Lisbon, Portugal. We’d been there 5 days and this place turned out to be just down the road from the hotel. Totally empty, we got the undivided attention of the (very dashing) Brazilian waiter and had an amazing and very cheap meal. Main course, dessert, wine, coffee and brandy for two for just 33 Euros.

If you’re in Lisbon for Euro 2004, check out Jardim das Saladas for great food.

Posted 17:56, 01 Sep 2003.  

September
Mon Tue Wed Thu Fri Sat Sun
30          

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Powered by Blosxom

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.