Try "If the only tool you have is a portal server, you will see every web application as a portlet"... and probably add 20% to your project as a result of needless complication to design, implementation and development environments.

IMHO, portal servers (everything implementing JSR-168) are a technology still waiting for the right problem to come along. Unfortunately, too many companies have brought the sales pitch and fork over big $$$ for the IBM and BEA suites and are using it for all web application development, irrespective of how devoid of portal-specific requirements the problem domain is.

I should note that I'd observed this team's standups for a week or so and they were short, energetic and focussed. The only issue was the developer's not feeling they got a lot of value out of them.

Note: I take most of what should/should not be in a standup from Jason's excellent article.

The client have been doing a great job adopting lighterweight process just from reading books, so I haven't needed to suggest too many changes to their daily working lives, just a tweak here and there.

But by far the simplest change we implemented is bringing the biggest benefits. The development team were using a story wall on a pinboard to track work during iterations, but due to the layout of the office, the pinboard was located upstairs in the development area and therefore only benefitting the development team itself.

My suggestion was to move the wall downstairs so it was visible to everyone in the entire company. Almost as soon as doing this, the marketing and sales people started asking questions about the purpose of the wall and quickly understood what information it was showing. They were most appreciative of being able to see what features were in development, completed or not yet started. Based on this increased understanding, conversations between the business and the development team increased and were based on a common understanding of the current state of development.

So, with the cost of a longer trip downstairs to update the story wall for the developers, it's ability to act as an Information Radiator was increased greatly.

Postscript: 2 days after the story wall was moved downstairs, it was joined by another story wall created by the marketing team to track their tasks :-)

Note: by the time of the technical interview, the code review has already been checked by other people and considered to be of a sufficient standard to continue the recruitment process.

There are many ways to discover information about the quality of the candidate in this part of the process: some obvious, some not so obvious...

However, I think I may have found a potentially valid reason why ClearCase is the installed VCS in so many shops - and it's all down to the value system of the customer...

Thinking back over this period and my own behaviour, I've noted a couple of work habits which I began using in a fury and then have dropped off quite substantially of late: debugging and IDE-based global string searches across the entire codebase. On reflection, I think both of these techniques are strong indicators that a developer has a poor mental model of the overall shape of the codebase as there should be no need to resort to using these very blunt instruments in an ongoing fashion when there are far superior alternatives which should make the need for debugging and global searching almost disappear.

Unfortunately, I didn't have the foresight to actually measure the number of times I fell back on debugging and/or global searches to answer particular questions, but I think it would make interesting reading as I know the number have dropped off markedly of late. Perhaps on the next new project...

A coach needs no deep knowledge in the subject's domain to assist them in discovering their particular solution, but is well versed in applying a question-based framework to encourage the self discovery necessary for the subject to uncover the solution.

Which is the conclusion I came to when I decided not to continue trying to integrate Log4J with Websphere (which is apparently not the walk in the park it should be) and just allowed Websphere to use it's native logging.

In the end, using the native logging system (Java Logging, methinks) gives me everything I need and the pain we were experiencing trying to force Log4J into the picture just wasn't worth the hassle.

One to the the Wookie!

"How many emails do you receive from your manager which have been originally sent to him and he's then forwarded them to you (and possibly others) with no change apart from the addition of an 'FYI'?"

In other words, how much value is being really added to the organization by this individual? Working within a large corporation, I'm frequently the recipient of emails containing up to three levels of nested "FYIs", as they've trickled down the corporate hierarchy to the worker bees.

Of course, if you find yourself forwarding on the same emails to others with nought but an extra FYI, then you might want to ignore this post :-)

Not surprisingly, the larger the bureaucracy, the more intractable the rules. For example, these are a couple of ones I've come across on client sites over the last few years:

Me:
"every minute I stay in this meeting, I get weaker, and every minute my team codes stories, they get stronger"

This is my mental picture of how the results of most project PIRs (Post Implementation Review) are handled by companies. Either the results of the PIR are filed away in some labrynthine file server, or the project team disbands and they're lost forever. Given the fundamental issues that seem to re-occur within environments that run large numbers of big projects, you would hope to find some organized approach to harnessing this collective experience on future projects, yet I've yet to come across such a beastie so far in my professional life.