As the consequence of a reorganization I have a lengthy new title at work:

Manager of Enterprise Architecture and Governance

I’m no longer a software development manager building up a team and delivering projects. In the near term I need to develop a charter, hire at least one new architect, and get started on some basic foundational work such as coming up with as-is and to-be models of our architecture.

I have some plans for how to be an effective enterprise architect team:

• Concentrate on people. Mentoring, training, and guiding people will help you implement the right architecture.
• Plan big, small steps every day. Incremental is the way to get there.
• Governance disagreements should be rare.
• The business needs to trust you. Confidence building takes gobs of time, but if you can’t keep convince your business customers, you can’t make the big changes.
• Architects must code. No one gets to step back and just spend all their time in UML and Powerpoint. Everyone has to spend some time on real projects implementing their ideas and getting direct feedback on how well things work.

Nothing like defining a new role from scratch to get me out of bed in the morning.

Glancing at a Hudson dashboard in the morning I crack a little smile. 9-10 project statuses are right there in front of me.

</p>

Great T-shirt on an audience member. </div>

I gave a two hour presentation on Hudson this week at our local Sacramento JUG on “Happy Builds with Hudson”. About 20-25 people showed and I got plenty of good questions from the audience. I did ask one audience question. By a show of hands how many people already have a continuous build. About 50% of the room raised their hands. The adoption rate is pretty good, but continuous integration is probably the easiest XP/Agile practice to adopt and half the room still hasn’t tried it out yet.

I covered Hudson fairly deeply including:

• Dashboard weather icons. Now you can see the recent status of your project at a glance, not just the last build.
• Static analysis plugins. They’ve added plugins to merge findbugs, checkstyle, PMD, and todo tasks into graphics with trend lines.
• Master-slave builds. Still haven’t tried this out or really needed to, but nice to know it’s there.
• Matrix builds. You can setup a single project, but define different JDKs, different OSes, etc and Hudson will automatically create builds for all of the possible options.

If you haven’t taken a look at Hudson and you’re not 100% happy with your current build tool there are just three steps:

1. Download hudson.war
2. Run:

   1	java -jar hudson.war

3. Open a web browser to http://localhost:8080

Lesson learned a few years ago:

Don’t bring your laptop to the meeting.

As an early wifi adopter I relished bringing my laptop to every meeting. Better efficiency, better note-taking, and instant gratification if you needed to Google something at the meeting. And just wrong.

The whole point of meeting is to make some decisions in a group setting. The laptop is a distraction. If you a scribe for the meeting you might be able to justify typing in everything almost verbatim, but for anyone else you just need to log the action items that come out of the meeting and maybe a few noteworthy discussions.

I had good intentions when I used to bring a laptop to all my meetings:

• Typing up notes right in the meeting saved transcription time.
• Heh, I’ve got that defect right here and it says it was closed an hour ago.
• Hold, on let me IM Sandra and see if she how many hours she has left on the redesign.
• Great action item, I’ll just compose an email and delegate it off right here.
• No, the server is up right now, I just pulled up the login page.

With a laptop at the meeting you’re constantly reminded that this person might have a point, but you could cycle through a few emails and really not miss out on anything. I’m sure they won’t notice a little bit of typing.

If you really could get more done just working on your computer, maybe this badly run meeting isn’t the place to be. What you really need to do is re-examine your need to be at the meeting.

Perhaps every few weeks I bring a laptop to a meeting. Two possible reasons:

• I’m actually giving a presentation with it.
• It might be useful to quickly check some online reference information like our bug tracking database or log files from a server outage. (It stays closed unless the need actually arises.)

Always use caution with email. Even an innocent signature line communicating the fastest way to reach you can be misconstrued.

I read Tim Ferris’s book a few months ago. Many different ideas on how to be more effective using less time. I tested out the idea of batching email and only checking it twice per day. Checking email at only 12:00 and 4:00 and batch processing saves at least 30 minutes per day. Successful experiment!

I had a simple addition to my signature line to explain this.

Due to increased workload I’m checking email twice per day at 12:00 and 4:00. Please call me on my cell at 555.555.55555 if you need to reach me sooner.

I got a bit of helpful feedback from another manager a few days ago. The suggestion was to maybe reword the signature line as some people might have construed it in a negative light. Email is dangerous that way, lack of context can lead people to the wrong conclusions.

The email explanation signature is gone now. The real gift was another manager comfortable enough to give feedback.

Fred George has broken developers into three broad groups of apprentices, journeymen, and masters. Based on this classification our team is moving from apprentice to journeymen currently.

He defines apprentice level programmers as:

An apprentice in OOP is a effective programmer and can construct loops, methods, and classes, but is still learning how to separate the business problem into objects. Encapsulation is being learned (which means no getters or setters for the classes). Code is being placed into the appropriate classes rather in giant god class. if statements litter the code as the apprentice is still learning design patterns to eliminate them. Class sizes and method sizes tend to be larger than smaller. Code requires comments to aid in understanding, and blank lines are common in the middle of methods to group code together. An apprentice is beginning to understand the patterns of bad code (the imfamous code smells), but lacks the tools to understand how to eliminate them.

Some of our developers are still dealing with this level, especially considering object oriented concepts can take a while to bake in. Lots of if statements in some code is still a sign that we have a ways to go. The blank lines in the middle of methods are great visual clues that a developer still needs some help refactoring.

Journeymen are defined as:

The journeyman is adept in OOP techniques. The classes exhibit crisp conceptualizations distinguishing them from each other. Boundaries are clear; methods are small. Design patterns are common, and exist in inverse proportion to the number of if statements. else statements are quite infrequent, and case statements have vanished. (I write about one case statement every 18 months or so.) Given a problem and a broad outline of a design, journeymen will implement it with little need for supervision or support.

When I see the rare if statement in a code review it will be a happy day.