Flutterby™! : good agile, bad agile 2007-02-23 19:19:52.444174+00

good agile, bad agile

2007-02-23 19:19:52.444174+00 by Dan Lyke 8 comments

If you're interested in software development process, Good Agile, Bad Agile is worth a read.

And the notion of "agile development" with everyone in the same room is... well... like a perpetual meeting. Meetings make you dumber (The actual Journal of Consumer Research article, from an entry on /.).

Hmmm... I jumped in on Ravi's post and being a little more mature than most programmers, I think I can see some of the arguments, good and bad.

First, the idea that Pair Programming keeps the programmers' noses to the grindstone is, in my mind, a very good point. Ravi's statement that the company needs to change it's hiring practices just doesn't deal with reality.

There are different "grades" of programmers. Some, like Dan, can shut-out the entire world through strength of will and maintain amazing focus and flow for long periods of time. Others, like me, need a little more cajoling to get into that space. I need to turn off the cell phone, close the email reader and browser and put on noise-canceling headphones playing essentially muzak. Sure, I can get into that space of focus and flow and maintain it for a good while (4-6 hours at time). And it's been enough to work various "miracles" over the years.

I first experienced this when Dan and I worked for Frank. This was 'back in the day' when cell phones were rare but not as rare as internet access (Dan ran a Fido node at the time and I was active on the WELL). Frank didn't let us have phones in our offices but we were allowed (and encouraged to close) doors on our individual offices. In that distraction-sterile environment, I would usually manage 2-3 "shifts" of concentrated flow a day. I did have to break up the shifts with a lunch break or something but Dan didn't (although I think he started to fall off after about 8 hours - probably due to changes in glucose levels more than anything).

I also think that programmers of Dan's "grade" don't benefit from pair programming. Dan's the kind of person who's concentration can blow out just about anyone's attention span. Forcing him into a pair-programming situation would probably drive him to quit and just make fancy tables with his groovy power tools. It definitely wouldn't make him more productive. That said, I've had to maintain his code and I would have benefited from a "structured walk-through" with him in order to understand the bigger picture behind his implementation.

I've worked with other folks like Dan since then. They are the kind of people who can make or break entire projects because they can knock out insanely huge chunks of an implementation while the folks like me can tidy-up the rough edges. And for me, it helps to have someone sitting next to me questioning each step because my attention-span blew out during the walk-through with Dan.

For context, I'm now working on my PhD. That involves a great deal of focus and flow but with absolutely no outside controls on distraction. Probably, the biggest reason people don't finish PhDs is that they found it too easy to procrastinate... like writing long comments in friends' blogs...

#Comment Re: Superprogrammers made: 2007-02-23 22:01:34.213757+00 by: m

Non DP management frequently does not have much of a concept of the supercoder. The one who writes 10 times as much code as everyone else in a day. The code which actually works, is economical of CPU and RAM, and has a clean interface. The person who can doesn't need (or want) meetings because they already have a clear model of the process that is to be accomplished.

I always saw meetings as pure punishment. I always did my best to return that favor for the person who called the meeting. But humor and sarcasm did not make me popular with certain segments of the organization -- those individuals who saw projects as something called work rather than play. The modern analogs of the pincer and red hot iron wielders of the inquisition. A pox upon them all.

I actually like pair programming for certain sorts of tasks, and it may be a good idea for focus in some situations, but my experience of it hasn't pushed me to wanting to adopt it for everything. And while it may reduce coding errors, I'm not sure that the slowdowns that can happen when two coders are at dramatically different levels are a good thing.

But that's not the part of "agile development" that raises my hackles. I have much more of a problem with the notions of the "bullpen", some aspects of the customer interface process, but mostly with the fact that most of "agile" is about throwing up strawmen and demolishing them, rather than talking to the real criticisms of the process (which is hard to pin down anyway), and about selling books and consulting services.

In the end it's the Dr. Phil of programming methodologies. It makes for good TV, but you can't really expect that it'll be a panacea.

First, I always thought a phone was bad because it was an attention span breaker - I don't know what I would do today with every one feeling its their 'right' to carry a cell phone - I probably would put a faraday box around the office walls to block the signals! Dan talked about a job he had where he was a programmer but the 'others' in the office would ask him to answer the phone while everyone was out!

Second, debuggng and stuck -- it is my contention that when a programmer is stuck trying to find a bug, a second person can walk in, sit down and in the process of asking the programmer to explain what they are doing, the programmer gets a mental break and in doing so is able to grasp the error. Its not the skill of the second person as much as it is the idea of the second person applying his mind to the issue which through some form of osmosis, causes the programmer to see the bug suddenly 'jump off the screen' - the same screen and the same code that just a moment before was bug free :) .

Of course if the said 'programmer' in my example has a mental resistence to the fact - and that 'there are no bugs in my code it must be somewhere else' then the second person has to gently steer the programmer through the logic of the code - knowing each step of the process is like chewing aluminum foil (apologies to Jimi hendrix) for the programmer - and painful. And the process has a quality in this case as if there is force shield around the whole situation whereby the programmer is sending out mental radio waves that say NO you don't! and the second person has to block those and if a bad part of the code is found the second person has to have the strength to arrive at and identify the bad code, or if the mental waves are too strong then the second person should at least say 'for the record I do not understand this code or whether it works'. I have seen it happen - rather I have been in the situation. (care to comment said programmer - vmem has no bugs)

Of course today the languages we use are not so difficult - with strong typing and so forth, unless the programmer is a 'cowboy coder' and just has to override the fail safes and do things like 'cast one type to another' because it saves registers (!), or write as much code on one line as can be squeezed in, making the code impossible to read by anyone but the writer - in effect 'write only' code.

On the other hand I once took a big section of code written by said 'cowboy coder' and rewrote the whole thing very structured, clearly written, and elegant, and easy to read, the kind of code you were proud to push into the version control system, and when I got done it was so slow I threw it all away and went back to the previous code which I could not read. But of course I never said anything and went on demanding clearly written code :)

A more coherent addition later, but... The particular thing I come to thinking would have been good to pair program was good old VMem.

Frank and I sat down one day and did a walk-through together on VMEM. The biggest problem we saw was that much of the code was written at a fairly early stage in your (Dan's) style. It was very different from your later code when you were exploring literate coding. And the bugs were exactly in the spots when Frank and I would look at each other and say "What the hell is going on here?"

The issue with the uber-coder is maintenance. Uber-coders HATE maintenance mode development and they frequently write code that is hard to maintain. Perhaps a different pair-programming model would be to assign an apprentice to the uber-coder. The apprentice's job is to go through the code after the uber-coder has written it and make it understandable. The apprentice would always be working one project behind the uber-coder and given regular but restricted communication with the uber-coder (like email). The apprentice could also act as the point of contact with the rest of the company for the uber-coder.

When the uber-coder finishes a significant chunk of code, he/she will meet with the apprentice and put together a presentation that the apprentice would give to the entire team (or the other apprentices). When the project is "complete", the apprentices would stay with the code into maintenance mode while the uber-coder goes on to the next project. Maintenance mode would involve traditional pair-programming.

Just an idea. Maybe I should give it a name like "Uber Development" and start consulting based on it...

And on optimization... I think it's relatively apparent now that, unless you are coding for a limited physical architecture (like squeezing a 1.5MB executable into 400K of RAM or trying to eek more polygons out of the PS2 display engine) then code-level optimization just obfuscates the code and introduces hard-to-find bugs.

If you find yourself bumping against memory sizes or processor requirements, then you have either an architectural problem (your data model needs work) or algorithmic (big-O uh-oh).

The code I write now will likely end up becoming part of a publication in a scientific journal. Since I'm not actually in Computer Science, I try to make code that's understandable by Geographers. I edit my code for clarity as much as I would the text of the publications.