Observations on Programming

I was reading an interview in Computerworld with Christophe Louvion (see page 2), the developer of Scrum programming, where he talked about “agile” programming and teams.

A couple points he made really struck a chord with me.

Programming Practices

Has agile become so mainstream that it’s become a trendy, meaningless buzzword?

The term agile is being used by [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][some] people to justify poor programming practices such as cowboy coding.

“We don’t have to write documentation; we’re doing agile,” they’ll say. Like with everything else, people are bending the rules to accommodate their personal preferences.

I’ve lived this. I won’t name names or projects, but I definitely think Christophe’s opinion has merit. I’ve been on a project where “agile programming” was “used”. Or at least elements of it like team programming and rapid iteration. However this technique was technologist-/programmer-driven, not customer driven. And therein lay the problem. The technique seemed to be as much a means of removing the programmer from good communication and customer interaction, as a means of developing the product. Unfortunately for the project, it took me a long time, working a number of different methods, to try and address the issues at hand. I think we had some limited success in the near term, but I can’t help but wonder what we did to the long term potential of the project.

The phrase “cowboy coding” also struck home. “Cowboy coding” is described by Kent Beck in another Computerworld article (see page 2) as:

In cowboy coding, you go off and you do heroic stuff, and you feel good about yourself because you figure there’s nobody else in the world that could have possibly pulled out something like this.

I’ll agree that there is a time and place for heroics and all that. But, when every release seems to rely on heroics to get it out the door, there’s something wrong.

And for the love of pete, document what you’re doing. Documentation’s not fun, I know I’ve done it. But, there are strong merits for doing it. (One of these days I’ll have to write my story about developing a video player for my Master’s project.)

Teams

Christophe goes on to say:

There is a good quote from the chairman of Toyota. Someone asked him, “What is Toyota’s advantage?” He replied, “It is our ability to get normal people to do outstanding things. Other companies try to hire outstanding people to do normal things.”

I have a corollary to this thought…we (I) try to hire outstanding people to do outstanding things. I’ve been blessed to work with some of the brightest people around. I’d like to believe that by hiring outstanding people, we’ve been able to do some pretty remarkable things.

It’s also probably true, that the chairman of Toyota was also cautioning about expecting outstanding people to only do “normal things”. Everyone at some time has to do “normal things”, and it’s definitely something to be concerned with if they’re expected to do outstanding as the norm. I think this is where it’s my job (I’ve been the manager) to enable the individuals and the teams to do the outstanding work, while still making sure all the “normal things” gets done.

Another thought comes to mind–definitely hire the person not the skills. Skills can be taught or learned, the intangibles that define the person cannot. Perhaps I’ve been extremely lucky in each of my jobs, but in many cases we’ve been able to hire the right person, and as a result have had some outstanding teams that did some outstanding work.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]