It’s 3:30 on a Friday afternoon and you just got the test passing for a nasty intermittent bug after spending most of the day on it. Now you can jump back into the main code base and add that new feature. Only, that would be a bad idea.

The Friday Rule:

Try to leave every Friday with a success.

You want to head into the weekend with a win. That win can be small, but carrying frustration into the weekend means you’re less effective next Monday. You walked away frustrated and probably thought about it over the weekend. Weekends are a critical for recharging batteries, spending time on hobbies, and hanging out with friends and families. They are not a good time to mull over bits of bad code or a misconfigured server. Walk out with a win.

There are some implications worth noting:

• Say you fix the critical bug at 2:00PM on Friday. Switch your energies to something lighter like clearing your inbox, filling out release notes, updating the wiki, or completing a mandatory online training class.
• If you’ve had a really long week already now is probably a good time to head home.
• From a coding perspective leaving a good breaking point is to write one last test that fails. Then you can easily pick up where you left off.
• As a manager when a developer swings by to explain how they finally got something working and you see it’s already well into Friday afternoon encourage them to take the victory with them over the weekend and not continue to code away.
• This can apply as a daily rule, but it’s more critical on Friday where you can affect your mood for the whole weekend.

I’m working on a justification for capable developer machines including dual 24″ monitors. It occurred to me that I needed a simple test to define the problem.

def test_two_24_inch_monitors_are_cost_effective
  baseline_productivity = developer.productivity_in_hours_per_year
  developer.add_monitor(24_inch_monitor)
  developer.add_monitor(24_inch_monitor)
  productivity_gain = developer.productivity_in_hours_per_year - baseline_productivity
  assert(productivity_gain * 50_dollars_per_hour > cost_of_two_monitors)
end

So with two 24″ monitors running say $800 I need to show just a 16+ hour increase to justify the increased productivity in a single year. To make the math easy with say 1600 hours available a year, we’re talking about just a 1% productivity gain. Given a recent study showing 20%+ gains this should be an easy test to turn green.

Browsing Howard Lewis Ship’s blog I came across a short post on his maven frustrations:

I still like the concept of the repository and the transitive dependencies; that aspect of Maven is worthwhile, but as a build tool, it sucks up far more time and energy than it saves. Possibly an order of magnitude more.

I’ve always had those same sort of frustrations with maven often due to a lack of clear documentation. Browsing through the shrinking computer section at Borders I chanced upon the O’Reilly maven book and with a 40% off coupon went ahead and picked it up.

In my current organization they were an early adopter of maven. Yes, that means we are running maven 1.0 in all its glory. Maven 1.0 was a failed experiment and led to a “complete rewrite”. We’re using maven 2 for new projects, but we’ll have some pain in making the migration for a number of older projects.

I just want to jump in and get some things done. With ant or rake this was easy. With maven it involved searching for documentation or looking for plugins to see if they existed. I’m really hoping the Sonatype book fixes that issue. It has a free online version as well.

About the time you realize UDDI doesn’t buy you that much another question comes up? How do we manage the services? Options include:

• Put it off because we only have a handful of services?
• Buy a product or possibly use an open source service repository tool?
• Setup something informal like a wiki?

When you have a small number of services you don’t really have an issue. All the developers know about them and they’re pretty well understood. Adding a registry might only buy you extra complexity.

The tool solution appears to be risky right now. My limited experience in this area is the tools are not mature. In one case the service repository tool became a sinkhole of development resources just to set it up and get it configured.

Martin Fowler recently mentioned an option that has always appealed to me in just using a wiki as a starting point.

We’ve seen a lot of fancy products being sold to provide service registry capabilities so that people can lookup services and see how to use them. This client discarded them and used an approach that combined wikis with some interesting data mining (more on that soon).

— Martin Fowler

Most wiki’s have versioning built in as well so the basics are all handled and updating is easy. I know I’ve really enjoyed using Confluence in the past, and just about any wiki should be able to handle the requirements. I look forward to hearing more.

One of our testers thought our ESB was broken. “Well, when I send in the payload against our main app it works so how come it throws an error here?”

“Because we’re actually validating the SOAP message”

“So is this other app.”

“Let me show you.”

At this point the developer created a quick XML message that violated the XSD by wrapping it in junk.

<junk>
real payload here.
</junk>

He sent it in and the other app happily accepted it. Might as well send a flat file at that point.