I ran across this quote in Peopleware:

The chemistry-building manager take pains to divid the work into pieces and makes sure that each piece has some substantive demonstration of its own completion. Such a manager may contrive to deliver a product in twenty versions, even though two are sufficient for upper management and the user. It may even be necessary to conceal some of these interim versions form the client and build them only for internal confirmation and satisfaction. Each new version is an opportunity for closure. Team members get warmed up as the moment approaches, they sprint near the very end. They get a high from success. It suffuses them with renewed energy for the next step. It makes them feel closer together.

— Peopleware 2nd Edition pg. 152

Way back in 1987 Demarco and Lister described a pretty good version of Scrum and why it works. Other than the idea of the non-transparent idea of concealing some of the demos of the versions it aligns almost exactly.

We had a conference call today with some IBM Websphere specialists on an issue we’re having with intra-portlet communication. They have been gently hinting that their customers should move to JSR-168 because they’re taking out the IBM portlet API. Still with enterprise software vendors you figure this will be a very slow process. Verbally today they made it quite clear that they plan on moving to JSR-168 aggressively, and that in Websphere Portal 6.0 they’re actually deprecating IBM portlets in favor of JSR-168. The mentioned the word deprecated at least four or five times in a short discussion around the topic.

Just to prove that they’re an enterprise vendor at heart they did explain that they’re also pushing SDO (Service Data Objects), which is no longer a JSR, (or at least an active JSR) but more of a push by an “industry consortium”. How that plays out is still an open question.

I tried to remove a small impediment today. Nothing hard, just some access form we have to fill out to allow content authors access to edit content on our intranet. It’s costing us a few days per content author, and no one can see any value add by going through the process. I shot off an email after the standup meeting to the network admins asking why we have to fill out an access request for such a simple request and who I need to talk about to change it.

I got my response also via email soon enough:

Well, in the good old days we used to do it verbally. Then we had to start doing it when we added access to a network share for the content authors. Now we need to do it for the portal content authors. Audits happen around here.

Apparently we’re not even sure who started the policy. That’s one of those details I’ll have to follow up on. I’m guessing our internal audits group. I may find we have an actual policy because we had an audit finding on this issue.

What I expect to find is we’ve fallen into this cover your butt policy because of some fear of a possible audit finding. That fear leads to an avalanche of costly bureaucratic policies at many companies. You know the sort of things you have to fill out an elaborate five page justification survey to have your helpdesk download some dangerous open source software like Perl complete with signatures from your CIO granting explicit permission.

I can’t figure out any reason for this form:

• We have complete knowledge of who has access to the intranet authoring via LDAP. This includes tracking of all changes by a given content author.
• All of the content being edited is simple informational content. The worst thing someone can do is accidently delete something.
• There are no licensing issues involved, our license to Websphere Portal lets us setup as many content authors as we want.

With luck, tomorrow we’ll be able to mark off the impediment.

We ran what I’m going to refer to as a code review mashup early this week on a project. The preparation looked like:

• Setup a meeting time for a 2 hour block by the tech lead.
• Setup the code review in Crucible selecting four classes written by three different developers including the lead about one day ahead of time.
• Added the three developers and myself as reviewers.
• Planned to walk through the code on an overhead and do more of an inspection.
• The morning of the review I took about 45 minutes to review 2.2 classes out of four and added about 15 comments to the code using Crucible.

I led/facilitated the review by going through all of my comments. Since I was the only one who had spent any real time prepping, the other developers only caught a few extra things. I think the big takeaway is everyone needs to review the code ahead of time. The last two reviews I’ve been in too much of a lead role, and not spending the bulk of my day coding I miss things other people can catch.

The review meeting ran much more like a code inspection or walk-through, essentially a code review inspection mashup. I’m not sure mixing the two styles really works all that effectively.

Still for about 8 hours of investment across four people we caught:

• A decent amount of coding convention misses, mostly naming conventions such as: <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1

  findBySSN

  </div>

  needs to be

  1

  findBySsn

• A design debate over whether to break up a fairly large JSF backing bean which is handling 5 physical pages into five separate backing beans or keep it in one. (We didn’t resolve this for now, but it is a future topic to consider.)
• Whether to use DTOs when using Hibernate or just use the Hibernate mapped model classes. We talked about the potential ease of not using DTOs, and the potential extra coupling of using Hibernate mapped models through the application layers. For now we’re using the DTOs.

My BS radar goes off when conversations turn to standards and best practices. I find James Bach’s argument quite convincing especially his point about industry best practices:

• “This practice represents a consensus among industry leaders.” No it doesn’t. You’re just making that up. Industry leaders aren’t able to agree on anything much of substance. I know this because I am an industry leader (based on the fact that some people have said so), and other leaders more often disagree with me instead of obeying my commands. I am influential within a certain clique. The software testing industry is made up of many such tiny cliques, each with its own terminology and values. </ul> </blockquote>

Standards are far too often used as hammers to enforce an individual’s ideas. They can quickly stifle creativity and lead to ludicrous decisions like using EJB’s for every project because that’s the industry best practice we’re following.

In Peopleware the alternate recommendation is to tend towards a “gently guided convergence” over hammering people with declared best practices. There ideas are:

• Training: People do what they know how to do. If you given them all a common core of methods, they will tend to use those methods.
• Tools: A few automated aids for modeling, design, implementation, and test will get you more convergence of method then all the statutes you can pass.
• Peer Review: In organizations where there are active peer review mechanisms (quality circles, walkthroughs, inspections, technology fairs), there is a natural tendency toward convergence.

— pg. 118 Peopleware 2nd Edition

Not a bad set of ideas, even if I’m not sure what a quality circle is.