Saturday, March 31, 2007

Emerging Tech

So I just got back from the Philly Emerging Technology conference, were I spoke Thursday morning about the wonders of process automation (using a cross-section of Maven, wikis and other tools) to shave those small minutes out of your developer's daily task list by automation - as well as the benefits of auditability (for example, track developer database modifications for SOX, etc). It was an interesting experience for two reasons:

1) I was coming down with a case of the flu, so besides trying to be coherent, charming, and professional, I also had to ensure that all fluids remained firmly inside my stomach and not all over the front-row audience (eewww....).

2) Many of the managers there seemed completely uninterested in making their developers lives easier through automating manual steps in their development process.

About the second problem, yes, developers should be somewhat involved in setting up their internal process - teams tend to work better when the players have a bit of ownership. But that is not what my talk was about. It was about automating those little pieces that project managers force their developers to do, for the sake of tracability or compliance. Why make your developers go to a "kick off" meeting and sign a sheet of paper to prove they were there, than instead have a wiki containing the necessary documentation and tell your developers to read it and sign the bottom of the page? It allows everyone to work on their own time, and you still get the tracability. You can claim "well, in a meeting we know everone is there." True, but I can just as easily no pay attention in a meeting and sign a piece of paper, than I can not read a wiki article and sign the bottom. In the end, its my fault if something goes wrong in either case.

I explained the problems of context switching, taking a developer away from his computer for 5 minutes, is likely to kill a half hour of productivity, since it takes time to get back into the groove (the groove factor?). My talk was about trying to remove those little interruptions, but mostly fell on deaf ears. From this experience, it looks like we still have a long way to go.

On the bright side, I did get to meet Dan Diephouse of XFire fame, Mike Rappaport CEO of Chariot Solutions, Patrick Lightbody from OpenSymphony, Phil Dodds from Simula, Gary Nakamura of Terracotta and many others. It's always nice to put faces with names.

Now if you'll excuse me, I have to go barf.

Friday, March 16, 2007

Code Te Ching Dups

I've started placing all of the Code Te Ching Verses on Whorapedia. I'll still try and post them here, but there will be first. There is a new crop - 8 more - out there.

Thursday, March 15, 2007

Code Te Ching - Verse 8

Over analyze and the mind will paralyze.

The elite does not dwell on effects.
He does what needs done and quietly steps back.

The best action occurs in the center,
Stray too far and you are soon lost.


I don't tend to post about myself much - but a lot is going on right now. I just had my first talk on Maven at the Kansas City Java Users Group last night, and it went pretty well. The upcoming Maven 2 book is moving along nicely and should be in rough-draft phase in three weeks - giving us 3 weeks of editing before going up on the (soon to be linked) website as alpha 1. We'll then bring in professional editing and get feedback before going to beta - then print. In two weeks I'll be in Philly convincing a room of managers about the importance of automating build process with a solid build infrastructure. Then we'll be at ApacheCon EU for a couple weeks, before coming back to talk at Java One. All of this while designing/doing training and helping Terracotta convert their project to Maven and working on Gatekeeper. It's going to be a hectic couple of months... let's hope I can keep bloggin' (hey, I still have 81 Code Te Ching verses to put out here... so there's always that.

Monday, March 12, 2007

Code Te Ching - Verse 7

When authority ends, process prevails.
   Process stifles talent.
The superior leader knows this.

Unlearn process: return to natural order.

Responsibility begets responsibility.

Wednesday, March 7, 2007

Code Te Ching - Verse 6

The perfect code is an empty screen.
    Perfectly formed,
    Perfectly extendable,
    Perfectly useless.

Therefore, the creation of code is an exercise in imperfection.

Monday, March 5, 2007

Avoiding Meeting Creep

I wish I could take credit for the name - but I can proudly say I need not take credit for the phenomenon. I can hear the sounds of knowing nods from here by the mere mention of the term: "meeting creep". Anyone involved knows it with no further description. These are meetings akin to the more famous "scope creep" with many of the same downfalls: soul-sucking wheel-spinning wastes of time and resources.

Like scope-creep, these types of meetings arise from the same source: everyone -- and can be halted by the same source: everyone, but more particularly management. These are meetings with several flavors. Those that take an hour where 5 minutes would suffice. Those that containing far more people than necessary (the invitations creep out). Those that span more than a single meeting ("Let's schedule another meeting to discuss that point"). Although everyone is ultimately to blame for allowing meetings to creep - almost invariably they are propgated by two kinds of people: 1) those who just plain enjoy the sounds of their own voice and 2) those who have nothing substantial to contribute and so drag meetings to fill their days.

The first group is simple to spot via consistent catch-phrases, such as: "Just to reiterate... (followed by the entire meeting relayed back to the conversation)" or "I just want to clear up a point for the group... (followed by something that everyone already understood)". This type of person often talks constantly, incessantly, at any time - meetings are merely another stage to let everyone know how insightful they are. This person will often ask obvious questions that do not need asking, simply to talk. Or he or she will make random offtopic points that never needed made, and repeat himself or herself ad nauseum. Whatever the vehicle - this person will end up talking at great length. Often times these guys are management - having been promoted for being "great communicators" - as if not being able to shut up were a virtue.

So how can we avoid this? The first group are actually difficult to stop, due to their seeminlgy innocent reasons for talking (how can you blame someone for not understanding? I find the simplest method for dealing with the first type are to keep notes and sit by them. When they begin to talk - before they can start to "re-iterate" or "clear-up points" stop them and hand off notepad, or tell the group that you will send out the meetings notes, and let the leader know that it's ok to continue - if the leader is saavy enough he'll catch your cue and keep going.

The second group are slightly less annoying - but tend to be management so may be harder to deal with. These are the kind of creepers that like to invite waaaay too many people to a meeting, or to split off meetings ad infinitum like some kind of Mandelbrot branch. If you have the choice avoid these meetings altogether. If not, your best recourse is to be proactive enough to stop a single meeting from becomming five. Oftentimes a single meeting will split because this kind of manager likes to "keep everyone involved" - translated as "I manage people, so the more people involved the more work I must be doing". If the meeting starts to sway into a direction outside of your domain - do not allow anyone to reschedule with someone else involved, for example: "We really need to get Johnson in here to ask about that DB issue - reschedule this meeting for Tuesday". You should grab the phone and call Johnson now. He may be available for a 2 minute question. BAM. You just saved yourself and everyone else another meeting.

There are certainly other types of meeting-creepers, and other ways to handle them. Ideas?