Thought for the day

Starting a new TFD section as I keep coming across things which pause you to consider. Hope you enjoy the updates !

We aree so afraid to take a risk for fear of losing that we end up missing out on the opportunity to win.

Breakfast Ride

Lineup at A1

Pascal was in town. Chatted with him on saturday and decided to meet up next day, but thought - hey, its been like a long time. Lets have breakfast on the Highway ! Pascal got in touch with GR and the deal was on. Later on contacted Swamy and Partha to meet up at Runway 9 to leave for the A1 for breakfast. GR called in evening to convey that Manju from 60kph and a Malaysian who was on an India ride was also going to join us for breakfast.

After ages, got up at 6am. Sleepy. Called up Swamy and Partha to wake them up. No replies. Gave up. Left around 6:45 and was at runway9 at 7:25am. GR and Pascal(pillion) came and we waited a bit more. Then this dude on a Beemer came up. Luggage loaded. Just started chatting with him and Manju showed up also. Decided not to waste time here and talk but move to the A1 restaurant.

Got to know that Ahmad Rosman was on a trip across asia and had to be in Darjeeling by wednesday. Spent time calling up people and finding out how good the route from Nagpur to Calcutta was. Did not get full details, but Ahmad decided to go anyways instead of doubling back to hyderabad and going via vijayvada.

Left the place at 9:45 back to hyderabad. As we came into the bad hyd traffic, heard a shout of 'Vibhu' ! It was my colleage from office Rejish. Told him I was just back from a 100kms or so breakfast ride ... he was flabbergasted.

How to make him understand why we ride ;)

Micromanaging and making Zombies

Came across an interesting article on how micromanaging makes people zombies all complete with a graph as below.

Now, ask any manager and he will tell you he does not micromanage. However, we do keep coming across such managers with a frightening regularity which makes me pause and think - why ?

Mostly I think it has to do with career progression. Most people join as lowly devs and become senior programmers, move on to team leads ... and then the transition happens. They look around and the future becomes very one sided. They see that the big pay cheques are where the managers are. So, they want to become a manager.

Not necessarily a bad thing, but management is a whole different ball game. From being a solo star, they have to become group stars and mostly they fail - miserably. That's where the micromanagement comes in. When alone, they had everything under them in control, and as they become managers they become control freaks. They NEED to know everything. So, they start to interfere in everything - and need a hour by hour breakup of what is everyone doing, in the misguided hope that everything will be going according to plan.

However, that never works out. Software work is never something that you can just keep doing all the time. It is done in fits and starts. Sometimes you are doing 200% and others just nothing gets done. Micromanaging in such situations leads to a zombieness. People stop thinking and just doing what is asked on a day to day basis - never thinking more or doing more than what they are told to.

But alas there seems to be no solution. The reward for good technical work is to become a manager and then (mis) manage everything. A comment at mini has the following :

I’m smart enough to know that I would not make a good manager, especially if my motivation for becoming a manager is simply to further my career. At least if I screw up as an IC, I’m not screwing up five other people’s careers.

Alas, not everyone is as wise or as selfless as that person. Till that time, we shall continue to get our creativity crushed under the micromanagers !

Software Development as a Cooperative Game

Software development has been compared to with different engineering disciplines ... mostly without success. Its been compared to bridge building, with automobile construction etc. Then, the big bosses, try to put in that methodology into Software development - with spectacular failure. And instead of finding a fault in the methodology or the 'Process' they are more liable to blame the people.

I think its cause of a) They not understanding the field , b) their big EGOs.

Unfortunately, if you work in a mid or big level organization, you are going to suffer these people, as they have mostly made their way up by sucking up and playing politics, not really by understanding how things work. Another reason is because they have been looking at all the wrong places to figure out how software works.

Alistair Cockburn has a fantastic article on what Software Development is all about. He compares it with Rock Climbing and I must say that it fits in better than any other theories I have read.

FTA:

I would like you to consider software development as a cooperative, finite, goal-seeking, group game.

Then he explains in terms of Rock Climbing ( i did rock climbing a long way back so the explanations were like 'let there be light' kind of revelation). The main comparisons from the article are :

Rock climbing is Technical. The rock climber must have technical proficiency. The novice can only approach simple climbs. With practice, the climber can attack more and more difficult climbs. The better rock climber can simply do things that the others cannot. Similarly, software development is technical and requires technical proficiency, and there is a frank difference in what a more skilled person can do compared with a less skilled person.

Training. Rock climbers are continually training and searching for new techniques they can use, just as software designers do.

Technical Pass/Fail. A key point of comparison between rock climbing and software development, for me, is that not just any solution will do. The climbers must actually support their weight on their hand and feet; the software must actually run and produce reasonably accurate answers. This key characteristic is missing from most alternative activities that people select to compare software development with.

Individual and Team. Some people just naturally climb better than others. Some people will never handle certain climbs. At each moment on the climb, the person is drawing on their own capabilities, have to hold up their own weight. The same is true in software.

And yet, climbing is usually done in teams. There are a solo climbers, but they are in the minority. Under normal circumstances, climbers form a team for the purpose of a climb and the team has to actually work together to accomplish the climb. Similarly, software developers, while working on their individual assignments, must function as a team to get the software out. The "Team - Individual" dual aspects of software development form the basis for most of my current work in methodologies, and I'll get back to it before I'm done.

Tools. Tools are a requirement for serious rock-climbing: chalk, chucks, harness, rope, caribeener, and so on. It is important to be able to reach for the right tool for the right moment. It is possible to climb very small distances with no tools. The longer the climb, the more critical the tool selection is. You software developers will recognize this. When you need a performance profiler, you really need it. You can't funtion without the compiler. The team gets stuck without the version control system. And so on.

Planning and Improvising. Whether bouldering, doing a single-rope climb, or a multi-day climb, the climbers always make some sort of a plan. The longer the climb, the more extensive the plan must be, even though the team knows that the plan will be insufficient, and wrong in places.

Unforeseen, unforeseeable and purely chance obstacles are certain to show up on even the most meticulously planned climbing expeditions, unless the climb is short and the people have already done it several times before. Therefore, the climbers must be prepared to change their plans, to improvise, at a moment's notice.

This dichotomy is part of what makes software development manages gnash their teeth. They want a plan, but have to deal with unforeseen difficulties. It is one of the reasons why incremental development is so critical to project success. (Does that sound like climbing in stages, and setting various base camps?)

Fun. Climbers climb because it is fun. Climbers experience a sense of flow while climbing, and this total occupation is part of what makes it fun. Similarly, programmers typically enjoy their work, and part of that enjoyment is getting into the flow of designing or programming. Flow in the case of rock climbing is both physical and mental. Flow in the case of programming is purely mental.

Challenging. Climbers climb because there is a challenge - can they really make it to the top? Most programmers crave this challenge, too. If programmers do not find their assignment challenging, they may quit, or start embellishing the system with design elements they find challenging.

Resource-limited. Rock climbing works against a time and energy budget, needing to be completed before the team is too tired, before the food runs out, by nightfall or before the snows come. In general, climbers plan their climbs to fit a resource budget. Similarly, commercial software development is governed by budget and need. It is in this sense that open-source development is different from commercial software development.

Dangerous. If you fall wrong on a rock climb, you can die or get maimed. This is probably the one aspect of rock climbing that does not transfer to software development. Rock climbers are fond of saying that climbing with proper care is less dangerous than driving a car. However, I have never heard programmers need to even compare the danger of programming with the danger of driving a car or crossing the street.

Have fun reading the article here (its quite long).