Launching a Development Architecture Team

After initially holding some development architecture decisions close to the vest with myself and the other web development manager, we decided to open up the process a bit to the senior developers on our teams. It’s an experiment of course so we’ll see how it goes.

The great benefit of opening it up is that you get a lot more perspectives and ideas. Just having the meeting opened up some surprises. It turns out after discussing what our default persistence layer framework and mentioning that we’re currently using iBatis by default but we’re looking at Hibernate or even EJB 3.0 that one of our senior developers have already put Hibernate into a module of a working product. After a discussion of source control options between CVS, Subversion, or Rational ClearCase we decided to stick with CVS for now and start exploring Subversion. Of course we also learned that at least one of the developer’s had already done some initial research and played with the Eclipse plugin.

The disadvantage is instead of coming to a consencus between one or two people, know we have to achieve concensus among six or more. Technical types can get pretty religious about things, but I think we have a pretty reasonable bunch so we’ll just have to see. We’ll be meeting every two weeks or so.

Getting IT Conference Presentations as Podcasts

Doug Kaye of IT Conversations has proposed the idea of expanding IT Conversations into capturing audio from presentations of all major IT conferences. Then the content might be released as a bundle for $50.00 or so as a new revenue stream for conferences. Since I can only afford the budget and time of perhaps one conference per year I think this is a great idea. I’ve been able to attend Web 99, Web 2001, and SD 2005 West over the past years and I’ve found these conferences really recharge my batteries. In fact even after attending SD 2005 about 4 months ago and pushing myself through it with a nasty case of shingles I got so many new ideas I’m still trying to figure out some ways to implement them.

The only problem I see with the model is the conference organizers have to agree. It might appear to them that if people can listen to the presentations later for a small fee, they might skip attending altogether. The other problem is finding enough volunteers to do the recordings, editing, and uploads. I’d volunteer here for any conference I attend once the details get worked out.

Riding the Bench in Software Development

At any given moment I probably have a handful of my developers who aren’t buried knee deep in coding, testing, or gathering requirements. They’re ‘riding the bench’ as the term went in the professional services world. In a consulting shop if you rode the bench for too long you were soon asked to be successful elsewhere. So proactive developers would always be trying to scrounge up the next client project, or volunteering to build a ‘useful’ internal software tool. The slower ones, the types you wanted to weed out of any good professional services firm viewed bench time as a bit of a vacation and attempted to milk it. That was generally a bad strategy.

In the more traditional corporate IT shops without the pressure to squeeze every last dollar out of their primary resources, their consultants, downtime seems to be a little more common. Typically it seems to come out of traditional project planning and resource allocation. The problem starts at the beginning of the project where the PM demands some development resources. Probably one of those resources is really involved up front in requirements. If you’re lucky the rest have some configuration work or research related to the project to work on. Often they’re underutilized until coding really gets underway. Then again in design the bulk of the developers are only peripherally involved, but hopefully there’s valuable prototyping and spiking to be done. Then the coding begins and goes until delivery. Even here things can slow down if a developer finishes a module early and can’t easily start a new assignment because of dependencies. Then generally we move into a testing phase and if the developers have done a good quality job along the way there are often few bugs and so again a lot of downtime. No one can be released though because they were ‘promised’ to the project and the sponsor would scream. Then even after a project’s deployed the business isn’t always ready with a backlog of projects for people.

Much of this stems from most corporate developments fixation on waterfall like processes even RUP run as waterfall. As I move more of our teams to a Scrum like approach I’m hoping to get much better utilization out of our developers. It was great to see on the first Scrum pilot project as the developers adjusted each day to take on new work, or help others get their assignments done that they kept busy with a minimal effort. I’m hoping to see this continue as we roll Scrum into more of our projects. Of course some individual developers are more or less motivated when seeing the option to slow down, but with short iterations and deliveries there seems to be added peer pressure to stay busy. I’ll have to see how well this works out on the next set of projects.

Spring: A Developer’s Notebook versus Pragmatic Project Automation

Having spent most of my spare development time the last few weeks playing/setting up my new 12″ iBook or revamping my blog with a move from pMachine to WordPress I’m getting back to investigating Spring.

I really want to enjoy exploring Spring, but the experience has been less then pleasant with Spring: A Developer’s Notebook. Generally I really enjoy O’Reilly’s quality with titles and after a pleasant experience marching through the Hibernate Developer’s Notebook, I figured the experience would be really pleasant. After about 10+ hours over several days back in early June I’m still fighting to finish up the exercises in the second chapter only 32 pages into the book.

Of course you can write me off as the village idiot, but the thing that’s really slowed me down the entire time is the huge amount of typos and missing context items that continue making working through the exercises difficult. My syntax errors are frustrating enough without the added problems of lots of errors in the book. I found at least two extra problems for the erratta in the first chapter and this is on top of the current list of errata. The typos are really annoying but a little more understandable for a first printing. The omissions of important items like which spring jars you might need to import are just painful. Things like the following:

  • By page 7 there’s a class described with no methods. Hunting through the errata you find out its supposed to have a constructor and a get and set method. Since I don’t assume to look at the errata first I wasted some time here.
  • Then the examples won’t work still in the first chapter and again it’s off to the errata page which I know have bookmarked. After checking the errata I find the authors forgot to mention you needed to import spring.jar, commons-logging.jar, and log4j-1.2.9.jar.
  • By chapter 2 we’re talking about an example file include.jsp, but we forget to actually print out the source code. Luckily that was resolved by downloading some of the example code to find it.

I don’t want to spend my time debugging example code, I want to understand what Spring is bringing to the table. To add insult to injury I submitted two bugs to the errata list. They have yet to be acknowledged after 4+ weeks and for some reason they aren’t automatically added to the ‘Unconfirmed Error Report List’.

I’m stubborn or I’d probably just put the book down in favor of Spring in Action or Pro Spring, because I only have so much time to devote to reading technical books. What I was hoping for was the experience I had with Pragmatic Project Automation. After a few hours over two days I had CruiseControl up and running and configured with a sample project and running email warnings and the like. Mike Clark’s examples just work.

Setting up CVS with pserver on Mac OS X 10.4 Tiger

Under the principle of eating one’s own dogfood, and in order to force myself to learn a few tools that remarkably few of my developers at work understand like CruiseControl, I’m taking a ride through setting up my own little pet project to do of all things keep track of employee comments I keep on a weekly basis so I have a history to refer to at review time.

For the first little part I need to get CVS up and running and I’m using this fellow’s site to get started. Not too painful, about 20 minutes and I had my CVS repository setup. Next is remembering the command lines to check in an intial test project.

Looks like the command to import a test project is:

cvs import -m "Test Project" test vendor-tag start

Turns out this doesn’t work right away, Apple has changed my default shell to bash of all things. Much more linux like I suppose. Have to move things to the bash profile. Not sure why they used tcsh in the first place, but I had gotten used to it, oh well, back to bash.

Anyway after running the command again:

cvs import -m "Test Project" test vendor-tag start

The repository is now created. So I have a CVS directory.

The next step is to setup remote access. Since I’m just running on my local network I’m just setting up a default pserver access.

Step 1 is to create the file


. The following text goes in there: (In my case it already existed from an earlier setup under 10.2)

service cvspserver
  disable = no
  socket_type = stream
  wait = no
  user = root
  server = /usr/bin/cvs
  server_args = -f --allow-root=/usr/local/cvsmain pserver
  groups = yes
  flags = REUSE

Step 2 is to restart xinetd. The wonderful Unix command is below that I always forget, -HUP something:

sudo kill -HUP `cat /var/run/`

Step 3 Add the username and encrypted password to a


file under the CVSROOT folder in the cvs repository: (Apparently this is new from Panther on and it works fine for me in Tiger)

sudo touch /usr/local/cvsmain/CVSROOT/passwd

Step 4 is putting in the

username:'encrypted password'

on each line of the file. I only needed to do one. And of course you don’t have the encrypted password so you can use a short perl one liner to get it:

perl -e 'print crypt "password", "sa"'


In the “password” field you simply replace it with your password. The “sa” clause is just some two letter expression, apparently used for the encryption process. This will print out the encrypted password something like:


which you can then add to the


file so that the first line should look like:



Step 5 you should be able to login now with the following command:

cvs -d :pserver:edgibbs@ login


As a final note it took about 30 minutes of tinkering and googling to get to this point where things worked. The key sticking point seemed to be the extra


file that had to be created and have an encrypted password in it. That seems to be new for 10.3 or 10.4 as back in the 10.2 days I didn’t need this step.