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.


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 :: 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 :: 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

Dysfunction: Avoidance of Accountability

The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.

Back to The Five Dysfunctions of a Team, so we have built up Trust, Conflict and Commitment. What do we need now?

Accountable: subject to the obligation to report, explain, or justify something; responsible; answerable.

In the model from the book, the avoidance of accountability is a psychological byproduct of the underlying dysfunctions of the team. Without firm commitments, after healthy disagreements are addressed, there is a tendency to not hold people accountable. We have a hard time holding people accountable, when we know they never really committed.

Ok. . . uhm, and?

How many of you have witnessed(participated in) the following scenario?

  • Incredible pressure to deliver a product/feature
  • Developers are hacking their little hearts out (very few tests being written, of course)
  • Quality Assurance is testing whatever they can see flying over the wall (with little or no prior knowledge of what it will be, bless their little hearts)
  • Product Management is doing whatever they do (anything but looking at what is actually being developed)
  • Daily stand ups where no problems are mentioned
  • We are so Agile, yay

Features delivered are a disaster. . . PMs are freaking out, Devs are indignant, QA is whimpering in the corner. What happens next? Rinse and Repeat. . . WTF?!??

I believe one of the fundamental principles of all Agile methods is ‘Reflect and Adjust‘. The built in adjustment is only going to help your team if it isn’t used as an excuse to ‘just do better next time’.

It is not only what we do, but also what we do not do, for which we are accountable.

– Molier

That doesn’t mean I’d advocate command and control shock and awe style, that just puts everyone into ‘cover your donkey’ mode and totally destroys the foundation of trust.

Honestly, Good Product Management is HARD. Good development is a creative endeavor that ebbs and flows. Good Quality Assurance is an acquired skill. All of these pieces are heavily dependent on each other.

Holding each other accountable doesn’t have to be antagonistic, but it does have to be honest. (truth, remember)

Brutally honest… Shit happens, but it doesn’t have to happen all the time.

Around the time of Caesar, there was a European tribe that, when the assembly horn blew, always killed the last warrior to reach his assigned place, and no one enjoyed fighting this tribe.

Don’t settle for mediocre, for yourself or for your organization.

Some people can’t handle ‘Truth’, and that is the seed for every other dysfunction.

Change your ‘organization’, or. . . change ‘your’ organization.

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

Dropping hits of Agile

There must be something in that water… what should we experiment with today?

add to :: 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: Lack of Commitment

He who is most slow in making a promise is the most faithful in performance of it.

-Jean-Jacques Rousseau

What is commitment?

When it comes to software development, there are two reasonable definitions:

  • the act of binding yourself to a course of action
  • confinement to a mental institution or hospital

And sometimes there will be great difficulty telling the difference.

In the ideal world, the perfectly architectured codebase has neat little modules with perfectly separated concerns, all perfectly tested of course. Santa Claus, Big Foot and the Leprechauns all love it, pay tons of money for it and are waiting patiently for the next version.

In the reality of software projects I have participated in directly, indirectly, discussed with colleagues or watched from afar, there are often competing internal and external pressures involving time, money, quality, ideology and last but not least ego. That isn’t to say that all these projects went poorly, it is just to recognize the pressures.

So what does all that have to do with commitment?

The Five Dysfunctions of a Team claims that unless the concerns of team members are not voiced and resolved through healthy conflict, the team will lack commitment to a clear course of action.

The original model targets executive decision making, which is paramount obviously.

But… effectively communicating these higher level objectives and the implications they will have in a software product or process in and among the development team, then being willing and able to adjust to the feedback may have an even bigger impact on a software company’s success in the long run.

That doesn’t mean all decisions require consensus to get commitment, but that dissenting voices are an opportunity to reevaluate, clarify and optimize. Simply exercising that opportunity can create an incredible sense of team duty in those who offered the dissent, even if they still disagree.

This is going to be a re-occurring theme, but if you are a software company, and you don’t have smart passionate people building your software, just give up now.

Seriously. . .

Now that there are smart passionate people building the software in a culture of trust and healthy conflict, get everyone unified and committed and you’re pretty much set.

With all the internal and external pressures, the success of a project and often a company hang in the balance.

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

%d bloggers like this: