Maven Frustration

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.

Service Registry

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.

SOA Silliness

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.

C# Coding Standards

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:

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.

Rotating Through


I recently rotated through a different management position for a weekend. It was still in IT, but I walked home late on Sunday realizing I learned a heck of a lot.

As a long time professional services guy I often miss the freshness of the new client. Just some of the clients I got to work with in a single year:

  • Fortune 500 pharmaceutical company
  • Multiple app server vendors
  • Online learning business
  • State of California licensing agency

Managing within a corporate IT arena you do get different challenges and you have a variety of internal business customers, but it’s still centered around the same business context.

I’ve been with the new company for about 6 months now and I’m still stumped by a fair bit of acronyms. I have gotten comfortable operating within the development sphere and a pretty constant set of business customers. Working as the weekend manager for a different IT group gave me some perspectives I wouldn’t have gotten any other way.

The most valuable part of the weekend was talking to various folks on other teams about how they saw the work they were doing and what they’re value proposition was. They were all tired. (This was weekend work) A lot of them were a bit down on morale. They all were trying to do the right thing. I made a few of them laugh when I asked basic questions about things they’d been doing for years. Like, “don’t you just reject a patch if the install instructions are all wrong?” The answer turned out to be no.

Taking a dive into a different area especially an area of the business works out your brain. I thought I’d be tired coming in this morning after working 12-14 hour days over the weekend, but I came back recharged and doing a bit more strategic thinking. And I can bring what I learned back to my team.