One way of organizing technical work on projects is to have a tech lead who architects the solution and divvies out the work. This is a high risk model often found on classic waterfall projects. Often the tech lead saves all the complex or interesting parts of the code and has the rest of the developers do the GUI or some supposedly less complex area of the code. This leads to:

• Less than motivated developers since they know they’re not trusted with the ‘real’ coding.
• No real way to speed up the project since things can only go as fast as the tech lead.
• Little mentoring since the tech lead is to busy coding to get others up to speed.
• At the end of the project very little improvement of the team for the next project.

I’ve seen this hierarchical model fail many times. The only time it appears to work when the project is small enough that the tech lead can pull off the superman role and code practically the whole app on their own. While common on waterfall projects, I’ve even seen this on Agile projects where the lead developer asks for less developers on the project because they don’t have enough coding tasks they want to give up.

Random trivia, but it turns out that the Google Mini uses special screws to keep you from opening up their box. Administration is purely through a web console. Our Unix sysadmins are a bit ticked about it, but heck it’s an appliance.

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.