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

1
/etc/xinetd.d/cvspserver

. 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/xinetd.pid`

Step 3 Add the username and encrypted password to a

1
passwd

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

1
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"'

</p>

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:

1
adfdie4JmERS

which you can then add to the

1
passwd

file so that the first line should look like:

edgibbs:adfdie4JmERS

</p>

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

cvs -d :pserver:edgibbs@10.1.1.5:/usr/local/cvsmain login

</p>

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

1
passwd

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.

Running Java 1.5 on Mac OS X Tiger

As it turns out you can pretty easily download the new 1.5 JDK, but there are a few wrinkles. It doesn’t become your default JDK unless you do some tweaking. In my case this involved IntelliJ as well.

The first step involves downloading the 1.5 JDK from apple.

I then assumed running

1
java -version

would show me the new 1.5 version. Instead I got:

>java -version
java version '1.4.2_07'

Next step is to change the default JDK:

>cd /System/Library/Frameworks/JavaVM.framework/Versions 
>sudo rm CurrentJDK 
>sudo ln -s 1.5.0 CurrentJDK 

Now when I run

1
java -version

I get the expected:

>java -version
java version '1.5.0_02'

After that I had to download IntelliJ IDEA 5 from intellij.net, because as it turns out the Mac OS X version of 4.5 didn’t support the 1.5 JDK. Makes sense since Apple didn’t release 1.5 until just recently so they couldn’t have built 4.5 to support it. Anyway it’s a bit beta software so far, but it does let force me to realize the new 1.5 context, which is part of the point. Now I’m up and running.

Spring versus EJB 3.0

In an article on O’Reilly’s On Java site, Michael Juntao Yuan compares Spring versus the EJB 3.0 spec. His essential argument is that EJB 3.0 “learned the lessons from Spring and Hibernate so well that, in most cases, EJB 3.0 addresses what most developers need with a standard API.”

We also learn in the scope of the article that Spring “is a popular but non-standard open source framework.” I’m really not sure what an how an open source framework is non-standard. This applies as well to ant, JUnit, log4J, and a host of other commonly used open source java tools. If it means it doesn’t have an official JCP blessed spec, then I suppose it is technically non-standard. And with open source frameworks popularity means its instantly more useful because of a large community of users and contributors.

Since even with the EJB 3.0 spec parts of it can be difficult to test outside of the container we learn that “in-container tests are recommended, as they are easier, more robust, and more accurate than the mock objects approach.” The reality is in-container tests are possibly OK for functional tests that CruiseControl runs, but they blow for unit tests as the overhead is simply far to high leading them to be commented out, etc. I’ve seen my developers fail to run unit tests over and over again because of dependencies on things like rules engine environment, JBoss servers, and databases. They simply take too long so they don’t get run.

I’m cherry picking things from the article here, but I don’t think it’s fair to come after Spring when the EJB 3.0 spec still isn’t finalized and won’t have much vendor support for a few years. And of course the author works for JBoss. And since I haven’t had to build anything that required EJB so far I find that Spring is likely to be a lot more useful to me in my everyday work. At the end of the day I need more easily testable POJOs, not another promise of better EJBs.