• 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.

“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.

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.

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.

– Martin Fowler

Software transparency to business experts is a great goal. I’ve met plenty of sophisticated business users who at least could do some basic SQL and whip together lots of nice reports in Excel. Those same users when presented with Java code lean back in their chairs and wait for the developer to show them a screenshot. Getting a DSL they can actually read and give feedback on means higher quality software.

I can’t claim to have reached this goal despite some attempts. So far the closest was a Fitnesse implementation validating business rules in some vendor software. The testers really took on creating scenarios after it clicked for them, but the business analysts still found it a bit to rough around the edges. Baby steps.

Fowler nails the point of DSLs from a business perspective. It sounds great to talk about business users writing the rules for the software. Every rules engine vendor makes this claim. In practice I’ve never seen it happen. Developers end up writing the business rules in the syntax of the particular engine.

Creating readable DSLs is great if you can communicate with the business experts. And even if you fall short the developers/testers get clear concise code out of the exercise.

Flipping through the Google Chrome documentation my brain was screaming–”This has to be Scott McCloud“. Turns out it was. Scott was a big deal back in the dot com days with his book on “Understanding Comics” and it’s applicability to designing web sites. I actually saw a great talk from him back at the Web 99 conference in SF. (That would be 1999). Nice to see him crossing back into the web world again.

The Chrome documentation is one of a number of new documentation styles I’ve seen recently. Screencasts are also becoming a popular way to do documentation and not just for high profile Web 2.0 frameworks but small internal IT apps. One consultant told me he had started doing all the documentation for their custom IT apps as screencasts. The customers love it because they can figure out how the app works quickly without running painful conference rooms of training sessions. And the flashiness of it is a bonus as well. To top it off it generally only takes a few hours for the developer to put it together. He mentioned the Peepcode screencast by Geoffry Grosenbach on Screencasting on the Mac was one of the best investments he’s made in a while.

As a developer, especially a developer who is comfortable building servers and slinging code in vi, you don’t want to hear the no word from the sysadmin. You want to be agile and install your own app. You want to configure the extra JNDI settings yourself. And you’re wrong.

I’ve worked in environments where sysadmins ruled with an iron fist on their environments and never let developers on production even to grab log files. Other places developers had wide open access. Wide open access is a bad, bad thing unless you’re still a small startup. Here’s the best model for a corporate IT shop.

• Developers own development for the most part. Sysadmins may backup the server on some filesystem, but that’s about the extent of it. Source control, wikis, continuous integration all run here. Developers are the primary users and everyone else is just visiting.
• Test is all about the testers. Testers should have access to tools like bug trackers and automated testing tools or servers. All the test servers should be locked down with developers and testers given read access to things like log files. Here the sysadmins begin to exert more control because test is the first step formal step in moving an app to production.
• Staging is a pure environment and developers are locked out here.
• Production is a no touch environment. Sysadmins have full control and troubleshooting issues means the developer sits with the sysadmin and doesn’t do the typing.

Developers need to stay focused on quality and not jump around troubleshooting environments. Good sysdamins will say no to developers touching production, but they’ll work closely with them to automate deployments and configuration. Remember they’re saying ‘no’ for your own good.

Keeping you backlog in order doesn’t tend to happen in isolation. My past experience is the backlog drifts because of a concentration on completing day to day Sprint tasks. You can tell when the backlog has drifted, the planning meeting goes long. Kane Mar suggests an approach of using a Story Time meeting.

A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work. This may include adding new stories and epics, splitting up overly large stories, and sizing.

At my past company this often came up as an issue since backlog items wouldn’t get estimated or explored much until the Sprint planning meeting. The idea is to have the product owner keep up with these items and follow up with people to get estimates as new items show up. In practice that just didn’t happen.

I like the idea of blocking out time to make sure it gets done and it helps ensure the planning meeting is smoother and over sooner. You wouldn’t need to use it with every team since some teams are just naturally better at making the time to keep the backlog in good shape.

Your local public library lets you check out books for a few weeks at a time. Developers shouldn’t ever use this as a model, but it can happen. A developer new to a language or framework is afraid to check in. Instead they wait sometimes weeks before checking in their first code. My idea of an ideal checkout time is 15-30 minutes. A day is really an extreme edge case.

Of course the shocking issue is some developers still don’t even use source control at all.

• The meeting has an agenda.
• The agenda went out far in advance.
• The leading has a strong owner who facilitates or helps keep the meeting on track.
• The meeting starts on time.
• Late people are ignored and have to bring treats to the next meeting or donate some small amount to a charity.
• Presenters are prepared.
• When discussions go to long they are put in a parking lot.
• The meeting ends 5 minutes early so you’re not late to your next meeting.

At a former company a new CIO showed up and started holding a weekly management leadership meeting. The first meeting people strolled in a little late. The CIO spelled out the ground rules. The last person in the room after the start time owed treats to the whole group the next time. I’m not sure how seriously they took it, but the next meeting several managers were late. In fact one manager came in more than 5 minutes late and tried to sit in the back. The CIO pulled out the chair beside him and beckoned the manager to sit beside him the whole meeting. And just in case the manager forgot he reminded him he should bring nice treats for the next meeting.

Unfortunately the company had an entrenched culture of lateness and bad meetings so most meetings someone still showed up late. I really thought having the CIO point out your tardiness was enough of an incentive to be early, but behavior can be hard to change.

If you’ve fallen into the a common poor meeting culture try running a crisp meeting even as an experiment. You’ll be surprised how different it feels to come out of a focused meeting.