Banishing Warlocks, Witches and other Magicians

Its TOO HARD

Thats some of the problem with software development, its that it is perceived to be too hard. Someone is compiling code from over here and deploying over there to those servers with those tns names, and you need to bounce the servers but in the right order and do the smoke test just after the database release and oh and how are we doing the patch fix? are we using properties files? and apache is down, its gone wrong, SOMEONE PLEASE FIX THIS MESS.

In steps your local friendly white witch, wizard or magician

The hero.  See all that stuff above? They figure it out, they compile the code deploy the ear, amend the classpath, delete that overriding properties file and alter the tnsnames so its no longer out of date.  Phew.  Magic.  They just turn up wave their indispensible wand, and (certainly in my book) earn their salt.  Who wouldn’t think that?  Just dont let them go, because … well we need them to do their magic………………………

………………..and therein lies the problem.

What a wizard might look like

What a wizard might look like

What happens if?

The wizard is unavailable? You are stuck. You have a truck factor of 1. You are in trouble and guess who is sitting exactly where they want to be?  Guess who is going to get their contract extended? Guess who is going to get a high performance objective/bonus?

Ignore the man behind the curtain

The magnificent Oz

The magnificent Oz

This picture will be familar to people of a certain age myself included. The man behind the curtain, is (of course) the Wizard of Oz, and what is appearing to be mightily important and magnificent is actually one person’s attempt to “blind with science”. (For those who have not seen the Wizard of Oz check out the plot) Often the “magic” a developer does to resolve a situation, especially in repeated circumstances is no more than pushing a few buttons and twirling a few knobs.  Important perhaps, needed definitely, but really tech?…… no.

Other problems

You have a wizard, a very capable developer, but the issue is worse than truck factor.  You have a system where you need to repeat things time and time again to test systems, to test deployments, and slowly you will find that the balls will drop, OH they get picked up as soon as the wizard realises that the old ear file was deployed instead of the new one or the wrong tnsnames got done this time etc…  But you have a very capable developer who instead of focussing on the developmental road ahead with it’s rewarding challenges, is instead juggling tasks.   But only they can do this stuff… only he or she has the pc with the correct maven settings or classpath or project setup.

The solution is simple

write stuff down

write stuff down

Probably many reasons (some discussed above) why people don’t already do this, but its always a worthwhile investment.  I mean who likes to think about stuff that you can write down anyway, I’d rather be thinking ahead.

When you write the stuff down, the magic disappears, and becomes tangible and useful within itself.  Maybe its actually a simple “copy and paste” with an ear file and another 1 line change to the “tnsnames” file, hey! guess what? We can get one of our junior members of the team to do this and they will learn something new, and hey! guess what? The team begins to improve, and freed up members of the team can work on the real problems at hand, without worrying about issues afoot.

Oh and use a wiki. Its great and often automatically version controlled too for auditing purposes. (not sharepoint, not sharepoint, and sharepoint NOT! sharepoint is flakey difficult and information hiding).

Summary

Writing stuff down:

  • Frees up the developer to work on more intuitive problems
  • Allows the team to work as a team and not a collection of individuals
  • Increases the team’s combined problem domain knowledge, lets call it the IQ of the team
  • De-risks projects
  • When stuff is written down, its easier to see how it can improve, therefore it improves collaboration
  • Saves time even in the short term
  • Increases truck factor
  • Not sharepoint (unless you are backing up the wiki)
  • Makes onboarding much easier, you dont need your top developer continuously spending time onboarding newbies as a result of more developers being needed because the project is behind.
Gandalf summarises

Gandalf summarises

Its ok Gandalf, the only loss is in that magic halo around the individuals who have the knack of solving those reccuring problems.  But Gandalf I say, dont fret about your powers, you can use them still but at the cutting edge of the problem solving.  The idea of breakthrough, is that one person or group breaks through, and the others simply follow through, and the team can simply stand on the shoulders of giants. But then you knew that because you are Gandalf the white now 😉

You might find some passive resistance, that then requires a bit of team cohesion, understanding and discipline which should be enforced.  Changing people’s mindsets is one of the most difficult challenges any leader or manager has to do, but simply by putting “write stuff down” on peoples goals or performance objectives could solve this. (Show me how you measure me and I will show you how I behave : Eli Goldratt)

So we need to banish the magic, and make those warlocks, witches and other magicians into team members again.

This entry was posted in Core Agile, lean, team, xp. Bookmark the permalink.

3 Responses to Banishing Warlocks, Witches and other Magicians

  1. Pingback: Cowboy Coders | AGILE78's Blog

Leave a Reply

Your email address will not be published. Required fields are marked *