Comments on: Surgical Team or Motley Crew of Adventurers? http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/ Isaac Schlueter on Web Development Fri, 16 May 2008 10:40:48 +0000 http://wordpress.org/?v=2.5.1 By: Peter http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-645 Peter Wed, 14 May 2008 15:50:16 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-645 Hey, I read this when you first posted it but forgot to comment. This was a very fun read. I hope you got lots of reads for this post. And your comment about how it's hard to find a build engineer who's happy in that role reminds me of the bad ole' Tech Support days. We had the same problem keeping anyone who actually tried to do good work in that position for more than 6 months. You get used to the near constant turn-over eventually and just work with it. Thanks! Hey, I read this when you first posted it but forgot to comment. This was a very fun read. I hope you got lots of reads for this post. And your comment about how it’s hard to find a build engineer who’s happy in that role reminds me of the bad ole’ Tech Support days. We had the same problem keeping anyone who actually tried to do good work in that position for more than 6 months. You get used to the near constant turn-over eventually and just work with it.

Thanks!

]]> By: Tim Rechin http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-404 Tim Rechin Sat, 23 Feb 2008 05:53:53 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-404 :-) That's my boy, Isaac. You complete me. :-) That’s my boy, Isaac. You complete me.

]]> By: Isaac http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-368 Isaac Tue, 05 Feb 2008 23:05:33 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-368 w00t. I've been <a href="http://digg.com/programming/Web_Development_Team_or_Motley_Crew_of_Adventurers" rel="nofollow">Dugg</a>. w00t. I’ve been Dugg.

]]> By: Isaac http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-316 Isaac Thu, 24 Jan 2008 20:26:26 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-316 Thanks, Stephen! Yeah, we're actually aching for a build engineer. For now, while we're in internal beta, it doesn't hurt so much, but it will be a much bigger problem once we go into production and problems are more than an inconvenience. The problem I've found is that the best build engineers usually really aren't happy being build engineers. :) Thanks, Stephen!

Yeah, we’re actually aching for a build engineer. For now, while we’re in internal beta, it doesn’t hurt so much, but it will be a much bigger problem once we go into production and problems are more than an inconvenience.

The problem I’ve found is that the best build engineers usually really aren’t happy being build engineers. :)

]]> By: Stephen http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-315 Stephen Thu, 24 Jan 2008 06:36:53 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-315 Very insightful Isaac! Really this is quite consistent with my experience. Although I think having a dedicated release engineer is very helpful. On our team we (the FEs) write our build scripts, but generally release engineering manages branching, installation and general ownership of what is installed on the boxes. Less crap in our brains to worry about. Very insightful Isaac! Really this is quite consistent with my experience. Although I think having a dedicated release engineer is very helpful. On our team we (the FEs) write our build scripts, but generally release engineering manages branching, installation and general ownership of what is installed on the boxes. Less crap in our brains to worry about.

]]> By: Kent Brewster http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-285 Kent Brewster Mon, 31 Dec 2007 17:22:05 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-285 You kids today, with your fancy character classes ... when I was your age, all we had were <a href="http://kentbrewster.com/webdev-character-classes/" rel="nofollow">wizards, fighters, clerics, and rogues</a>. :) You kids today, with your fancy character classes … when I was your age, all we had were wizards, fighters, clerics, and rogues. :)

]]> By: Isaac http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-219 Isaac Thu, 06 Dec 2007 02:07:56 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-219 @Matt Doar So... then everyone who doesn't write code is a "toolsmith"? Repository, check-out, and branching strategies are specifically delegated to the Clerk, in Brooks' and Mills' model. Of course, with the advent of CVS and SVN, this is no longer really a full-time job on all but the most complicated projects. The toolsmith is the one who creates the tools that the team uses to create a software project. I guess a build script *could* be seen as a part of that, but again, that's usually not a full-time job. (I wrote the installer and build script for the front-end of our site, and I also do lots of front-end stuff. The back-end packages are each handled by whichever engineer owns that bit of functionality.) My other tools are either created by me for my use (bash scripts, Quicksilver shortcuts, etc.) or I get them from third-parties (Apple, Unsanity, TextMate, etc.) In 1975, it was not uncommon to build and set up your own workstation for coding, and this could potentially take a lot of time. I really don't think Brooks is talking about build scripts, here, but more like hard drives, memory, and monitors, as well as reusable macros and such that would be used to help streamline the creation of assembly code. For our team, the "big" part of that job is done down the street in Cupertino and up the coast in Redmond, and the "small" part of it is done by each user on their own machine, since it's not a full-time job to whip up a few shortcuts when you need them. @Matt Doar

So… then everyone who doesn’t write code is a “toolsmith”?

Repository, check-out, and branching strategies are specifically delegated to the Clerk, in Brooks’ and Mills’ model. Of course, with the advent of CVS and SVN, this is no longer really a full-time job on all but the most complicated projects.

The toolsmith is the one who creates the tools that the team uses to create a software project. I guess a build script *could* be seen as a part of that, but again, that’s usually not a full-time job. (I wrote the installer and build script for the front-end of our site, and I also do lots of front-end stuff. The back-end packages are each handled by whichever engineer owns that bit of functionality.)

My other tools are either created by me for my use (bash scripts, Quicksilver shortcuts, etc.) or I get them from third-parties (Apple, Unsanity, TextMate, etc.)

In 1975, it was not uncommon to build and set up your own workstation for coding, and this could potentially take a lot of time. I really don’t think Brooks is talking about build scripts, here, but more like hard drives, memory, and monitors, as well as reusable macros and such that would be used to help streamline the creation of assembly code. For our team, the “big” part of that job is done down the street in Cupertino and up the coast in Redmond, and the “small” part of it is done by each user on their own machine, since it’s not a full-time job to whip up a few shortcuts when you need them.

]]> By: Matt Doar http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-218 Matt Doar Thu, 06 Dec 2007 01:53:30 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-218 Isaac wrote: "I had thought that [the role of a toolsmith] referred to the task of creating customized tools for the actual *creation* of code; editors, workstations, and such." I think of a toolsmith as helping a team to create software products, only part of which is writing the code. Tools to help with that are just one part of the job. Isaac wrote: “I had thought that [the role of a toolsmith] referred to the task of creating customized tools for the actual *creation* of code; editors, workstations, and such.”

I think of a toolsmith as helping a team to create software products, only part of which is writing the code. Tools to help with that are just one part of the job.

]]> By: Isaac http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-216 Isaac Tue, 04 Dec 2007 23:24:46 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-216 I suppose you could call that job a toolsmith, but that's not what I thought of, and I'm not sure that's what Brooks and Mills had in mind. (Maybe I'm wrong.) I had thought that this referred to the task of creating customized tools for the actual *creation* of code; editors, workstations, and such. For example, I have a bit of Applescript that I run from Quicksilver that starts up 3 tabs in iTerm and gets all three running with a given set of commands that I like to have running. (Syncing my mac to my BSD machine, tailing the apache logs, and sitting in the code folder for command-line CVS.) I have a few bundles that I use with Textmate, and plenty of debugging tools in Firefox. In the old days, that kind of stuff (or rather, the corollary tools for assembler coding and debugging) would have been built in-house and customized by each team. On my current project, I wrote the build scripts that set up the development environment and build the production site, simply because I've had to manage badly implemented sites, and so it was important to me to get it right and not feel that pain again. Our bug tracker is just Bugzilla, and Yahoo! has plenty of standards for that, but I suppose at a smaller shop, it would perhaps be a significant job to set that up. The buglists themselves are managed by the project manager, product manager, and QA. (And, of course, we update bugs when we fix stuff.) CVS strategies, code folder structure, and coding conventions were settled using the Benevolent Dictator approach: <ol><li>One engineer is declared the Dictator of the problem.</li><li>The Dictator makes a proposal, and writes it up.</li><li>It's debated for no more than 1 week, during which time everyone has a chance to weigh in. If you don't speak up, then you don't get heard, period.</li><li>The Dictator takes what everyone said, and makes a decision. Their decision is final unless it causes serious unforeseen problems.</li></ol> It's amazing how well this works. Everyone gets to have their say, and on most teams, the Dictator feels a real responsibility to take what everyone said into consideration, but debate is limited, so it doesn't take long. The Dictator isn't anyone's "boss", so it doesn't feel it's a power trip. In the end, John Q. SpaceIndenter doesn't mind using tabs, since it feels like he's part of the team. I would have thought that branching strategies and repository management would have been done by the program clerk. Nowadays, our "clerk's" name is "vault", and we talk to it via CVS :) I suppose you could call that job a toolsmith, but that’s not what I thought of, and I’m not sure that’s what Brooks and Mills had in mind. (Maybe I’m wrong.) I had thought that this referred to the task of creating customized tools for the actual *creation* of code; editors, workstations, and such. For example, I have a bit of Applescript that I run from Quicksilver that starts up 3 tabs in iTerm and gets all three running with a given set of commands that I like to have running. (Syncing my mac to my BSD machine, tailing the apache logs, and sitting in the code folder for command-line CVS.) I have a few bundles that I use with Textmate, and plenty of debugging tools in Firefox. In the old days, that kind of stuff (or rather, the corollary tools for assembler coding and debugging) would have been built in-house and customized by each team.

On my current project, I wrote the build scripts that set up the development environment and build the production site, simply because I’ve had to manage badly implemented sites, and so it was important to me to get it right and not feel that pain again. Our bug tracker is just Bugzilla, and Yahoo! has plenty of standards for that, but I suppose at a smaller shop, it would perhaps be a significant job to set that up. The buglists themselves are managed by the project manager, product manager, and QA. (And, of course, we update bugs when we fix stuff.)

CVS strategies, code folder structure, and coding conventions were settled using the Benevolent Dictator approach:

  1. One engineer is declared the Dictator of the problem.
  2. The Dictator makes a proposal, and writes it up.
  3. It’s debated for no more than 1 week, during which time everyone has a chance to weigh in. If you don’t speak up, then you don’t get heard, period.
  4. The Dictator takes what everyone said, and makes a decision. Their decision is final unless it causes serious unforeseen problems.

It’s amazing how well this works. Everyone gets to have their say, and on most teams, the Dictator feels a real responsibility to take what everyone said into consideration, but debate is limited, so it doesn’t take long. The Dictator isn’t anyone’s “boss”, so it doesn’t feel it’s a power trip. In the end, John Q. SpaceIndenter doesn’t mind using tabs, since it feels like he’s part of the team.

I would have thought that branching strategies and repository management would have been done by the program clerk. Nowadays, our “clerk’s” name is “vault”, and we talk to it via CVS :)

]]> By: Matt Doar http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-215 Matt Doar Tue, 04 Dec 2007 18:16:05 +0000 http://foohack.com/2007/12/surgical-team-or-motley-crew-of-adventurers/#comment-215 You wrote: "The need for a full-time toolsmith has been all but completely surpassed by the customizability of workstations and the availability of many high-quality tools for coding and such." From my perspective, a toolsmith is the person who handles both the tactics and strategy of the version control, build system, bug tracker, test automation etc. That's a full time job for any team greater than about a dozen people writing code. Out of interest, what does "toolsmith" bring to mind for you? You wrote:
“The need for a full-time toolsmith has been all but completely surpassed by the customizability of workstations and the availability of many high-quality tools for coding and such.”

From my perspective, a toolsmith is the person who handles both the tactics and strategy of the version control, build system, bug tracker, test automation etc. That’s a full time job for any team greater than about a dozen people writing code.

Out of interest, what does “toolsmith” bring to mind for you?

]]>