Little observations

Posted by Jeremy Miller on November 13, 2007



  • Stale code is dangerous.  My poor colleague tried to merge code from a class that’s basically a directives file today.  He had kept his code out for a month.  When I was much younger my father would gently mock me about my propensity to foul out of basketball games.  Guess who played the “I told you so Father” role today?  (I did help him through the merge).  One more time with feeling, stale code is evil.  Check in often.  Work in small steps so you can check in often.  If you can’t check in often, update your copy from the master frequently.  You can keep the nasty merges away without retreating to pessimistic locking.  Walking out of the office at night with modified code on your workstation needs to feel like going to work in the morning without a shower.


  • Side note:  I worked with a quirky developer at my last job that used to say “Uh oh, it looks like another learning opportunity” anytime he or we suffered an episode like my colleague today with the merge.


  • Note to self:  get better with SVN Merge


  • Keep the build server clean baby!  The build server today caught a problem with a VS project reference that wasn’t apparent on a developer workstation.


  • Frequent checkins plus the SVN Revert command == ugly code be gone


  • Cubicles == Collaboration Proof Force Field.  Is there any worse way possible to arrange a development team?


  • A team building a feature is far better than a group of individuals doing tasks.  It’s the same amount of work, but somehow the team/feature combo working with a shared purpose produces more real value than a bunch of disconnected individuals working tasks in a project management worksheet.


  • Something smells if you sit in a meeting for an hour and are only impacted by 5 minutes of that hour.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://simeonpilgrim.com/blog/ Simeon Pilgrim

    @Russell – my server issue is more of a IO concern with developer directories on a server, gigabit ether gets swamped quickly. As to CI, why would you do integration testing when your not integrating it? It’s a personal branch. So points where really, compiling code that sitting on a non-local disk doesn’t scale. Long periods of not check-in code into the trunk is bad. I find personal branches a solution that fits my needs.

  • http://www.geekswithblogs.net/coredump Russell Ball

    @Simeon – I don’t agree that disk space considerations should be a major factor in determining check-in policy. My working folder is only a small portion of the space I am using on my network drive. Most disk space issues in my organization have been addressed by putting policies in place about storing large personal files such as mp3′s, movies, and photos. Relatively speaking, src text files don’t take up that much room, especially since you are only keeping the most current version.

    I also have some concerns about the affects of using one personal branch per person would have on the effectiveness of continuous integration practices. For example, would you run a separate continuous integration build for every person? If so, that will introduce some major overhead and scaling problems on your build server. If not, then I question whether code will be integrated frequently enough. If I have to go through a two step process to integrate my code (checking it in and then merging my personal branch), then I will probably reduce the frequency I do this as much as possible. This will negate the effects of getting more immediate integration feedback.

  • http://simeonpilgrim.com/blog/ Simeon Pilgrim

    @Russell – Working folders on servers doesn’t scale to large teams, or large projects, or both. I agree trunks shouldn’t have 101 check-ins a day. Keeping a personal branch in sync is no harder than keeping a working folder in sync. In fact it’s the same effort. Because nobody else is changing your personal branch. You then check-in a larger change-set to the trunk/project branch. Seams it’s on the server, your version uses code based space per user, where-as a branch uses delta’s. This all assumes your using a real repository tool.

  • http://www.geekswithblogs.net/coredump Russell Ball

    @Simeon – I disagree. I think working folders should be mapped to a network drive on a server that is backed up. The purpose of backup is to make sure you don’t loose work. The purpose of source control is to be able to logically manage changes, revert to prior versions, and easily diff files.

    I like branching, but merging has its own overhead associated with it, so I prefer to only use it to manage production branches or major functionality forks for very large teams. I don’t think it is worth the overhead to have every person have their own branch.

    @Jeremy – I agree. CI is key, but I although the idea is becoming mainstream, I don’t think the practice is quite mainstream yet. I just started a new job and set one up for them. They recognized that it was a good thing, but I don’t think they ever would have gotten around to setting it up if I hadn’t taken the initiative.

  • http://simeonpilgrim.com/blog/ Simeon Pilgrim

    @Russell,

    Branching. Make a branch, do days work, check-in, merge from the trunk, check-in again.
    Source control IS a personal back-up. It’s on the server, your desktop hard-drive isn’t.

    @Jeremy,

    I find DiffMerge from SourceGear (it’s free) to be so much better than SVNmerge. When used as described in the help, it’s quite nice.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Russell,

    You said the magic words — “Continuous Integration”

    I really can’t imagine doing software development in this day and age without at least the bare bones basics of CI.

  • http://www.geekswithblogs.net/coredump Russell Ball

    Good observations.

    On the source control issue, I think it is also possible for developers to go overboard on this advice and check changes in too frequently. I’ve seen lots of developers view source control as a personal backup system rather than as a repository for a working build. When this happens you get all kinds of bottlenecks occur with people checking in non-working code that breaks other people’s code.

    I think as long as you have a continous integration system in place that runs tests and you have set up a culture where it visible and a bad thing to break the build, then you can encourage very frequent check-ins. Otherwise, I would temper this advice with a warning about the integrity of the build being paramount.

  • http://haacked.com/ Haacked

    If you ever wondered what the point of Twitter is, it is little observations like this. ;)

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Carlton,

    I don’t think I can do that with my client’s manager, but I got a chuckle out of it. In the bad old pre-Agile days I used to keep a notebook or my computer with me to work in meetings and just scan for keywords.

  • Carlton

    Two comments:

    “Team building a feature is far better than a group of individuals doing tasks” – lately I have been trying to lead a Scrum team where there is no Sprint Backlog. In exchange, I make sure during the Sprint Planning Meeting everyone understands the goal of the Sprint and commits to the user stories. I will tell you how it works out.

    “Something smells if you sit in a meeting for an hour and are only impacted by 5 minutes of that hour.” – institute the “Law of Two Feet” from Open Space. If someone is not getting anything out of a meeting within 10 minutes, they can leave no questions asked.

  • http://huntjason.spaces.live.com JH

    Ahh… I see that a stringent dose of RUP is helping you see the light on the true business value of lengthy meetings and inordinate amounts of shelf-ware documentation. (sarcasm intended)

  • http://grabbagoft.blogspot.com/ Jimmy Bogard

    It smells worse if you realize that the 15 other developers in the meeting are impacted by exactly 0 minutes of that hour, and are lucky if the meeting is only an hour.