I finally got around to updating the Crucible beta today. Crucible is a code review tool from Cenqua. Everything went fine until I started it up whereupon one of the update sql scripts failed. I went ahead and found a post on the exact same problem in their forums and uploaded the related file. Just four hours later the updated fix file showed up on their forums.

And this is for a beta product you can’t even buy yet. If this had been a call into IBM about a Websphere portal issue it likely would have been a day or so to get a response and a good possibility that we’d never get a fix without figuring out a workaround ourselves. And for this we pay the big bucks.

Small shops are just typically better about service, and they typically really need their customers. And just as a disclaimer we have purchased Cenqua’s Clover product and an Enterprise license to IBM’s Websphere suite.

One of the most heartening things developers at our shop have done is start a sort of technical book club. About a year ago one developer got really into patterns and suggested running some sessions around a particular pattern. It branched out later to two developers and now every two or three weeks one of them runs a session on a pattern for an hour or two.

The format has morphed a few times, but overall it’s a really good sign that as a development organization we’re still looking to improve. And the best part is I had no part in the idea. All I did was agree to order about a dozen copies of Head First Design Patterns. Soon they’re going to swap out and do chapters of Effective Java, so I’ll be ordering some new books.

Our organization decided officially to employ Use Cases for all ‘Agile’ projects about a year ago. I’d been advocating the practice for the past two and half years, but historically we did requirements one way:

The system shall …

Since our adoption of use cases on Agile projects we’ve seen rapid adoption of the technique among everyone but the business analysts. On two of the Agile projects they’ve been forced to use use cases, but on all the others they’ve effectively balked or let someone else take on the business analyst role. So only about 20% of the business analysts have ever written a use case for a project. They have all been trained in at least a two day intensive course on how to write use cases. Instead:

• A developer wrote the use cases on one project.
• On another a developer/product owner wrote the use cases.
• On two projects PMs took over the use cases.

The transition to a newer technique for gathering requirements would seem to be easy in most organizations. Use cases are demonstrably better for defining functional requirements that a lot of ‘system shalls.’ In prior professional services projects I introduced them to our whole consulting firm, and several large government clients, who saw the value and adopted them wholeheartedly, though in many of these cases they had no dedicated business analyst organization.

My assumption is that the business analysts are balking at change. From my standpoint writing up “system shall” documents would quickly drive me nuts and anything from use cases to user stories would appear to be a nice change of pace. I’m still not sure how to help convince them that there are better ways to document requirements.

In the near future I’d like to experiment with user stories, but I fear leaving the business analyst group even further behind.

A few weeks ago I gave my opinions on James Shore’s idea of manual continuous integration.

Today the continuous build for one of our projects has three steps:

1. Check in code to CVS repository.
2. Log into the build box and manually run a <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

   1	cvs update

   </div>
   

.</li> 

  * Wait for cruisecontrol to run a build and send out email notifications.</ol> 

Our other projects have a two step build:

  1. Check in code to CVS repository.
  2. Wait for cruisecontrol to run a build and send out email notifications.

The reason for the three step process is simple pragmatism. After you spend 40+ hours between yourself and a developer trying to get it to run you should look for something that works. The problems we ran into were numerous:

  * Turned out figuring out how to run maven2 from cruisecontrol was a bit annoying. We ended up having to use the mvnscript command instead of mvnhome. The note in cruisecontrol&#8217;s documentation was a hint at the problems we&#8217;d see:
> Due to the current status of Maven (in heavy development) only the &#8220;script&#8221; start mode is supported.

  * Then for some reason we still haven&#8217;t been able to figure out the <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
      <table cellspacing="0" cellpadding="0">
        <tr>
          <td class="line-numbers">
            <div>
              1<br />
            </div>
          </td>
          
          <td>
            <div class="text codecolorer">
              scm
            </div>
          </td>
        </tr>
      </table>
    </div>
    
    plugin in maven just didn&#8217;t work for updating from CVS from cruisecontrol. It would just bomb on the pserver password over and over despite the fact that the user it was launched under already had a valid
    
    <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
      <table cellspacing="0" cellpadding="0">
        <tr>
          <td class="line-numbers">
            <div>
              1<br />
            </div>
          </td>
          
          <td>
            <div class="text codecolorer">
              cvs login
            </div>
          </td>
        </tr>
      </table>
    </div>
    
    performed.</li> 
    
      * Next we tried just adding an extra ant target to do the CVS checkout. That didn&#8217;t work because cruisecontrol would checkout the project from the first ant command, and then return success and complete. It turns out you can&#8217;t run an ant and maven task within the same project.
      * Then I tried setting up two project, one to just do the checkout, but I couldn&#8217;t get the dependencies to work in cruisecontrol.
      * Then I tried luntbuild which was a bit of pain to setup, but finally looked like it was going to work. Only as soon as it starts to run maven2 it fails and exits with an unsuccessful build.
      * Then I tried to look for an ant task to run maven from ant. Turns out you can run ant from maven, but the [tasks](http://maven.apache.org/ant-tasks.html) are only for utilizing Maven&#8217;s artifact handling features.</ul> 
    
    The worst part is that in the past 30 day Sprint we&#8217;ve missed important build failures including several checked in unit tests that were failing and lately even some missing files that were causing the compiler to fail.
    
    So we&#8217;re back to manual continuous integration instead of investing more time in the tools.

As a manager you’re often privy to information that isn’t necessarily passed down the chain or broadcast to line employees. Many managers horde much of this information and unwittingly lose out on a lot of good information.

If you regularly hold back information from employees they will soon learn that sharing rumors and news with you is a one way street. Their answer is simply to stop sharing. And often times your employees have quite a few bits of info you’re not privy to because they have their own networks within the company.

The fear of sharing information with your employees probably stems from the idea that information is power or that sharing information with employees will just cause them unnecessary worry. The truth is not sharing with employees will certainly cause them more worry and damage their trust in their manager.

I regularly speak to my team and individuals on my team about almost anything. Some items that are worth sharing include:

• Explaining budget cuts or last months financial numbers.
• Giving at least my opinion on why a particular executive might have left the company.
• Passing along any information gleaned about a corporate headquarters move or a possible merger.
• Explaining proposed changes in technologies that will mean developers have to ramp up on something new.

The best payback is that I get back just as much information from my employees and everyone can act more rationally and spend less time worrying. And that means a more productive team.