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.

Due to a peculiar set of circumstances I’m looking at C# coding standards or style guides. The key decision is to agree to a style guide that everyone more or less follows. I also like style guides that go a bit beyond how to format the curly braces on a newline or tabs versus spaces. I like rules like this:

Define small classes and small methods.

— Rule #69 The Elements of Java Style

At a previous organization:

1. I bought a bunch of copies of The Elements of Java Style.
2. I handed them out to all of our developers.
3. I ran a brown bag lunch covering the top 10 rules I wanted them to concentrate on.
4. We checked most of the style items in the continuous build with Checkstyle. Gentle enforcement.

A quick perusal of the C# world says there isn’t any base coding standard like Sun’s Coding Conventions. I’m a bit surprised since I expected Microsoft to have at least attempted to do so, but other than the things you can glean from heaps of example code it doesn’t appear they have a well documented default.

The candidates from fifteen minutes of googling appear to be:

• C# Coding Style Guide from icsharpcode.net.
• The iDesign C# Coding Standard. from iDesign.
• C# Coding Standard from Philips Medical Systems.

The ic#code standard is concise and covers the basics. The iDesign option is more comprehensive. A quick skim did found a rule I don’t agree with:

Avoid methods with more than 200 lines.

Two hundred lines is ripe for refactoring to many 10-20 line methods. Still it is a lot more in depth. The final Philips standard attempts to combine rules from their C++ Coding Standard, the ECMA C# language spec, and an MSDN Design Guidelines Library Development document.

I’m pretty open at this point to suggestions from any of you who have spent a lot of time in the C# trenches.