Wednesday, September 17, 2003
Brozilla is staring at you
While cleaning out some old email, I found a reference to Brozilla, a totem we used at Blue Ripple. It was a plastic Godzilla toy. If you checked in code that screwed up the build, Brozilla was put on your desk as a "scarlet letter" so you wouldn't do it again. You got stuck with Brozilla until the next person screwed up. This was inspired by something we had done at Applicon years ago. An coconut carved to look like a gorilla head was hung outside your cubicle if you broke the build.
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since we have developers in several countries. Sometimes breakage is the result of sloppy or careless coding -- fortunately that's rare. Sometimes breakage is a result of miscommunication between developers. Refactoring is sometimes a cause as well. Refactoring code on a large project, even when you have access to all the code and have effective refactoring tools is hard -- especially when you have multiple development streams. When lots of code is changing at the same time, team size gets in the way. It can feel like the old Three Stooges routine where Moe, Larry and Curly all try to get through a door at the same time. The harder they struggle, the less likely any of them will get through the door. Breakage is inevitable when too many people try to change the same code at the same time.
Refactoring on a large project can be compared to the Big Dig central artery project here in Boston. It was hard enough to do the project in the first place but the really hard (and expensive) part is that Boston can't shut down while they work on it. The project needs to progress incrementally; allowing the city to still operate. This adds (and adds and adds...) to the overall cost of the project. The end result is a compromise from might have done if they had had free rein. Software refactoring can be like that too. Big changes need to be scheduled carefully and you have to avoid breaking existing code while you're changing the underlying support.
It's easy to say "Well, you have interfaces, right? Just change the underlying implementation and no one should notice." That's true to extent when interfaces have matured but interfaces evolve. And sometimes they're just plain wrong or requirements have changed to such an extent that you need to rethink your approach.
Comment time again: how does your development team deal with build breakage? How do you avoid it? What do you do with repeat offenders?
(Note: Brozilla belongs to Andrew Wharton. Here's a photo of Andrew and Brozilla in earlier times at Iris. It looks like Smart Money's Map of the Market on his screen. Very different stock market way back in 1999...)
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since we have developers in several countries. Sometimes breakage is the result of sloppy or careless coding -- fortunately that's rare. Sometimes breakage is a result of miscommunication between developers. Refactoring is sometimes a cause as well. Refactoring code on a large project, even when you have access to all the code and have effective refactoring tools is hard -- especially when you have multiple development streams. When lots of code is changing at the same time, team size gets in the way. It can feel like the old Three Stooges routine where Moe, Larry and Curly all try to get through a door at the same time. The harder they struggle, the less likely any of them will get through the door. Breakage is inevitable when too many people try to change the same code at the same time.
Refactoring on a large project can be compared to the Big Dig central artery project here in Boston. It was hard enough to do the project in the first place but the really hard (and expensive) part is that Boston can't shut down while they work on it. The project needs to progress incrementally; allowing the city to still operate. This adds (and adds and adds...) to the overall cost of the project. The end result is a compromise from might have done if they had had free rein. Software refactoring can be like that too. Big changes need to be scheduled carefully and you have to avoid breaking existing code while you're changing the underlying support.
It's easy to say "Well, you have interfaces, right? Just change the underlying implementation and no one should notice." That's true to extent when interfaces have matured but interfaces evolve. And sometimes they're just plain wrong or requirements have changed to such an extent that you need to rethink your approach.
Comment time again: how does your development team deal with build breakage? How do you avoid it? What do you do with repeat offenders?
(Note: Brozilla belongs to Andrew Wharton. Here's a photo of Andrew and Brozilla in earlier times at Iris. It looks like Smart Money's Map of the Market on his screen. Very different stock market way back in 1999...)
RSS 0.92 Feed