The point is missed

Museum of public mistakes and unfinished projects

Do you dampen or amplify?

leave a comment »

Today I rediscovered a thought I had months ago and forgot about. I was talking to a team-member about software development in general and frameworks  and processes in particular. What I’m about to write is just a theory and a thought model that seems useful to me. If you are looking for hard facts then this post is not for you (sorry).

I have this idea that all practices we apply are somewhere on a scale from dampening to amplifying. Did I hear a WTF? I’ll try to explain…

Dampening and amplifying – some background

I use the terms dampening and amplifying metaphorically. If you studied electronics you know that you often use a combination of dampening[attenuation] and amplifying to separate the desired signal from undesired noise. Think of a radio, you tune in to your favorite radio-show at 104.8 MHz FM. Part of what happens in your radio is that the receiver suppresses, dampens all frequencies except 104.8 (+- tolerance) MHz and amplifies the 104.8 signal so that it can be decoded into music or whatever you listen to.

You could get away with doing dampening exclusively, like when your signal is strong enough but you want to filter out undesired noise. The opposite is also true, if you have  a signal that has no noise, you could just amplify it. This is of course extremely simplified but works as an illustration.

Now imagine software development as a signal, the desired signal is continuous customer satisfaction being deployed regularly. Or to simplify things, delivering excellent software to our target group efficiently. You want to tune your team into that channel. How do you do it?

 Dampening bad behavior

It seems to me that a lot of processes start close to the extreme assumption that people have a desire to do bad things and unless you prevent them from doing that… they will. Using our radio-metaphor this would be an environment with extreme static.

If your starting assumptions are close to this extreme it makes sense to look for dampening practices and introduction of control. Such dampening practices can be implemented as process, technically or both. An example would be a tollgate system where at each tollgate a select few, typically non team members,decide wether or not whatever is being built can pass to the next tollgate or be rejected.

Technical enforcements could be the use of various tools. I am a Java-programmer and I find that Java often has a dampening strategy. Remove things that people find difficult in order to keep the language easy to use; at least for the vast majority of programmers. The downside of course is that programmers that would be comfortable and more efficient with those advanced features are also deprived of them.

Keywords: prevent, reject, suppress.

Amplifying good behavior

At the other extreme we assume that people have a desire to do good things and with freedom and opportunity that is what they will do. Again, using our radio-metaphor this would be an environment with no static.

If your starting assumptions are close to this extreme it makes sense to look for amplifying practices. The signal is clean, turn the volume up to ten. Amplifying practices tend to align views and remove obstacles. An example would be communicating a clear goal in terms of purpose and business value so that everyone knows what is developed for what purpose. Another example is removal of obstacles: the team says that the off the shelf product is not adequate for their needs, lose it! The team needs some infrastructure, get it! Some company internal process prevents the team from being effective, fix it! (either the process or the teams views)

As some of you may know I have been playing with Scala recently. The philosophy of Scala is very different from Java. Most programmers will find a lot of the things in Scala difficult, but hey, they can learn them and if they do they will be more effective so why should they be removed? What about dynamic languages? What if you choose a more powerful language than Java and instead of removing all “difficult things”, even for the ones that know them, and instead educate as necessary? That would be amplifying.

Keywords: enable, accept, encourage

Remove interference

A third option is to remove interference. Removing interference is deceptively similar to dampening but with the exception that you don’t suppress the unwanted noise, you find the source and remove it (or move away from it). In some hospitals there are still signs that you must keep your cell-phone switched off since it can interfere with sensitive medical equipment (at least that is the reason that is given on the signs). Interestingly enough the hospitals trust complete strangers with this great responsibility. Flight crews do too. You have to put your toothpaste in a plastic bag but something so lethal as a cell-phone they kindly ask you to switch off :)

Going back to our team, perhaps we don’t have to be so careful making everything harmful impossible to do. Perhaps sometimes we can assign some great power and freedom to each other and simply agree on how to and how not to use that power… then turn the volume up to ten…

Keywords: eliminate.

I will probably have reason to revisit this subject with more concrete examples later but this post is already hideously long. Until I get around to that (with my regular posting frequency it will be sometime next year), please read about the party planning exercise here and think about how it relates to the dampening/amplifying metaphor.

Written by johlrogge

March 30, 2009 at 9:45 pm

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: