Monthly Archives: April 2008

Shared Metaphor: Gnome Cloud Meat Pastries 2.0

The problem with communication … is the illusion that it has been accomplished.

– George Bernard Shaw

Underpants ????? Profit

One of the topics arising frequently in my conversations is the need for clear vocabulary to describe emerging concepts forced by technical evolution and how those concepts fit into to a personal understanding of the world.

Dialects arise, but until we have shared symbols and metaphors these discussions must always be clumsy. (after we have shared vocabulary, it will still mostly be clumsy)

This is a feeble (and misguided) attempt to share some metaphor.

Gnomes: Some of you might know of venture funded technical start ups that are going to change the world. Some of those start ups might have ridiculous valuations and little or no revenue. Some just have no revenue. . . at least they have a business plan, good luck with that.


Clouds: Everyone knows about ‘the clouds‘ Or maybe they don’t? Or maybe the whole point is that they don’t? Or something? Some anonymous thing over there does something like this other thing I once knew and could touch. . .


Meat: Every organization probably has some hardware and some software, but even in sophisticated technical endeavors there are niggling little tasks that probably should have been automated a long time ago. How are those tasks accomplished? Meatware. . . but of course.


Le Patisserie: This might be less common for some, but I fear those of you in software might have lived it in one form or another. This might also be referred to as ‘dessert tray‘ Agile, or euphemistically as frAgile development. You take one part flailing development organization, two parts buzzword compliance, cut in some shortening or lard, and then bake until golden brown, top with whipped cream and viola! Sprinkle with legacy code if you want a real treat!!

Now comes the fun part. . . mix and match. I haven’t found a permutation that isn’t relevant, informative and amusing. (Ok, so I might be easily amused)

Cloud Gnomes – a virtualization startup

Meat Pastries – developers doing mind numbing repetitive work with Agile razzle dazzle fairy dust.

Meat Clouds – Uhm, like. . . built the pyramids and make your shoes

I leave the rest as an exercise for the reader:

Gnome Meat Pastry Clouds

Cloud Pastry Gnome Meats

Pastry Meat Cloud Gnomes

. . .

Pardon me, I have to get back to playing with puppets . . . and gathering underpants.

Advertisements

Homeland Secured?

The man who would choose security over freedom deserves neither.

-Thomas Jefferson

I’m spending this week with Luke working on Puppet and since he lives a good long walk from where I live, I had to spend three hours on a flight to get here

I haven’t done a lot of traveling in the last few years, and apparently I have been missing out on some real fun at the airports. (For the last few years, work and home have all been in a 5 mile radius, which I was nice.)

Approaching the security check point, as I was being inundated with signs and sounds concerning what is and isn’t allowed through, I realized that I had a bottle of cologne that was definitely over the limit. This isn’t super fancy stuff, but it was a gift and I didn’t want to lose it. Realizing this, I asked the gentleman checking my boarding pass, the last step before the XRay conveyors, and he suggested I pull it out of my carry on and put the cologne through the XRay machine by itself.

So, that’s what I did. I took the 4.2 oz bottle of cologne out of my luggage, put it on the tray, with my wallet and cell phones, and proceeded through the metal detector. I found the take-your-shoes-off shuffle a bit disconcerting and slightly dehumanizing, but that’s the world we live in and I don’t get to make all the rules.

Here is where things get interesting, the cologne gets through without a second glance, but the XRay crew wants to confiscate my 80% empty tube of toothpaste.

Uhmm, Ok, take it, a small sacrifice to balance out the universe and keep my bottle of cologne.

So I re-shoed and went on my merry way.

Now I don’t pretend to understand all the issues of why I can no longer travel with toothpaste, and I certainly don’t begrudge the young man doing his job, I just find a certain irony in the capricious enforcement.

Why is this on my blog about software development?

Does your team have any (silly?) rules about how something should or shouldn’t be done? Are those rules arbitrarily enforced based on whim and circumstance?

Can you not check in a mostly empty tube of toothpaste, but it is perfectly acceptable to commit the 4.2 oz cologne, if you put it on the XRay conveyor by itself?

Problem Solved

I’m sure code everywhere will sleep better tonight knowing that your process protects it. . .


Less is More . . . doh!!

Smaller projects are more work, not because they are, but because they encourage a business to pile a bunch of them on top of each other.


Best Practices TM

Perfection is attained by slow degrees; it requires the hand of time

– Voltaire

Some say there are things you never want to see being made, if you like them.

Sausage, politics and software to name a few.

Here is the dirty little secret, no one in software or IT really knows the BEST way to do anything. . . no one. . .

It’s true. period.

I fondly remember a scolding I received from Robert Mecklenburg, when I used the term ‘Best Practices’ in the context of a code review. I credit him for forever altering my personal understanding of the concept.

‘Best’ implies a comparison, a hierarchy. There can be no ‘Best’ without a relationship to ‘Good’ and ‘Better’. How can you know the ‘Best’ solution without knowledge of all possible solutions?

How can you know anything is the ‘Best Practice’? Perhaps we should call them Seem-Like-A-Good-Idea-Today Practices. . . Or maybe Next-Time-We’ll-Know-More Practices . . . How about This-Seems-To-Work-OK Practices. . .

You can apply this from the barest metal all the way up the software stack to the tippy top of the user interface, from code conventions and software processes to feature planning and meeting agendas, pretty much anything that has to do with anything that isn’t already perfect. (that’s a lot of ground to cover)

That’s doesn’t mean there aren’t good practices or even great practices. There are certainly great programmers and sysadmins.

But next time you hear someone talking about ‘Best Practices’, ask them how they know. (And maybe what they are trying to sell. . . Who knows it might be what you need, but its probably not the best, at least not provably so)

I think context is also important, what works best in one context can be a disaster in what appears to be a similar context. Further, context is constantly changing. New hardware, new software, new team members, new problems to solve, that’s one reason reflection and adjustment are critical. We can’t know the best practice, but that shouldn’t stop us from trying to find it for ourselves and our teams.

Today’s ‘Best Practice’ is tomorrow’s quaint notion.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook


Dysfunction: Inattention to Results

Never mistake motion for action.

– Ernest Hemingway

The final dysfunction from The Five Dysfunctions of a Team is Inattention to Results. This ultimate team dysfunction occurs when members of the team value something other than the collective goals.

This dysfunction doesn’t mean they have lives and balance outside the context of the company (that’s another post. . .) but that the members of the team are focused on highlighting their own achievements regardless of the overall outcome.

You can smell this dysfunction when individuals or groups start to point to everything they did right, even when the overall project is flailing. (maybe especially when it is flailing)

“Product management did such a good job of creating requirements, its those lousy developers that didn’t understand, I mean just look at this pretty document. Don’t you love the font . . .”

“I wrote the code exactly to the spec, not that those idiot clients and product managers know what they want anyway . . . I am a programming god.”

Have you ever participated in either side of that conversation? Played Not-my-fault-I-am-teh-awesome hot potato?

(Quality Assurance gets blamed for everything, cause as everyone knows ‘kwalytee’ starts with the last people who touched the software, duh. . . You do have QA, right?)

There is nothing so useless as doing efficiently that which should not be done at all.

– Peter Drucker

Inattention to Results is most damaging to an organization when it becomes institutionalized processes. When people stop trying to do the best thing and just make sure they go through the checklist.

When things go South, the checklist becomes a buzzword compliant shield, an Agile security blanket.

When I first read the model, I thought the most important dysfunction to address was trust, because it is the foundation of all the other dysfunctions. After a little reflection, I’m starting to think that you need at least as much focus on results, if not more. Sure you need to work on trust, because if you don’t, eventually the rest of the dysfunctions grow to be monstrous, but ‘winning’ gives you the opportunity to work through a lot of trust issues. Especially, if working on trust (. . .conflict, commitment, accountability. . .) is an explicit goal.

This is all well and dandy, but what does that mean? How can I use this?

There is not a formula that you can just plug in and solve this problem. On some level, this is all about culture. On another, an individual, not on top of the food chain, recognizing these dysfunctions has to navigate between Scylla and Charybdis. One becomes faced with the prospect of being at odds with the perception of management, watching and suffering the dysfunctional culture, or finding something else to pay the mortgage.

(eh, maybe that’s why the book’s target audience is executive teams. . .)

Insanity: doing the same thing over and over again and expecting different results.

– Albert Einstein

what to do?

Reflect and adjust my friend. . . Reflect and Adjust

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook


Love me some raganwald

Estimating software projects is hard, hard, hard and it usually ends up being a poker game.

What’s the best way to play?

Depends on what you are trying to win

Gimme da Truf!?!!


Where Does Design Stop?

Link love for Michael Feathers

Outside the Design Boundary

I’m working my way through Working Effectively with Legacy Code (Robert C. Martin Series) which I traded to Zhon Johansen for The Five Dysfunctions of a Team.

I really wish I read the Legacy Code book sooner, solid techniques to bring gnarly code under test, one unit at a time. Practical, Practical, Practical

Live and Learn


%d bloggers like this: