I'm working on some software. Doesn't really matter what. But there is a DB. And of course since its evolving software there are migrations based on some version. The first "migration", from version zero to version one, is really setup. Okay, easy enough. The second is really a migration from version one to version two. I'm adding the third migration now.

At this point the original author had a choice. He (lets assume its a guy) could have made an infrastructure that walked through all of the necessary setup, from version zero to one etc. Or he could do what he actually did and added this in ad hoc, which not only requires me to read and understand all of the code (no black boxes) but also requires me to make the same choice. Incidentally, doing either way required the same amount of code, so there's no argument that doing thing ad hoc is "simpler", unless you equate not thinking things through as simpler. In fact, the ad hoc way is worse in terms of lines of code, but that's just because the author doesn't believe in DRY. Developing infrastructure is also more readable, too.

As you can probably guess, I'm making the infrastructure. Which means I am tearing down what the author previously did, doing things "the right way" (at least, the extensible way), and also correcting the DRY and other conceptual problems left by the original author.

I'd like to make it clear that its not like the original author didn't have the talent or understanding to forsee these issues or their social implications. He is on a mission to do agile development -- that is, solve the immediate problem in the "simplest" way possible. He would probably consider this text as well as my attitude on DRY to be intellectualist and elite. But I could say the same thing about his attitude towards developing software through "agile" methods. And since this is a monologue, I will.

Don't get me wrong, I think that the agile world has much to offer the programming world, which has traditionally gotten mired in the ideas that programs should be big, complex, and completely thought out up front with five lines of documentation per line of code. I do believe that software should be feature driven. I do believe that things should be implemented in the simplest way possible. Software development has become very bloated, and there's no reason for it to be. Software development should be simple.

What I do object to is the anti-intellectual position taken by some "agile" fans. Note that I'm not talking about people that walk around and say "I'm agile". That's a whole different problem. Self-identified or not (and usually not, in my experience), I have encountered many coders that think that their solution is best because it is simple. And if its dirty, so much the better.

Why I object to this is two-fold. Firstly, its reactionary. And like all things reactionary, its swinging too far the other way versus the collective pendelum that has swung out of alignment. Its easy to show that agile development only makes sense in the scope of common sense -- try to write any sizeable program like a web framework one feature at a time. Without at least a little design up front in the sense of "what the fuck are we talking about?", agile is fucked. Of course, on top of the technical problems, there is the attitude problems, which makes it hard to consider the virtue of what is actually being said in light of the arrogance of the sayer. Its an attitude like this that leads to the code I'm objecting to here. Its not actually simpler, by measure of lines of code, readability, or any other measure I can think of except that this is the lazy way of solving the problem. I'm all for laziness. Except when I have to sweep up after the original programmer.

The second problem is exactly this. If you are a lone developer working on a piece of software for a client, then yeah, use whatever methodology that you want. Lord knows when I'm developing something myself I use a different development style than when I'm working for others, because its only a dialogue between me, myself, and I. But if you're working with others, then being "agile" is often at the expense of your colleague. The original author writes sloppy code. He gets his laurels and moves on to writing more sloppy code. Meanwhile, to make his code work or to extend it, another programmer has to put forth more effort than is fair to clean up after the original author. This is my central point, so let me say this again and rephrase: the original author has an incentive to code more sloppily so that he can get more agile development done and so that he can put himself in a role where others are cleaning up after him instead of vice versa. Somehow the image of the cartoon races come to mind where one care peels out before the green light and splashes mud on the windshield of a competitor. So if this is what is meant by agile development or XP, I consider it socially irresponsible and encouraging of competition rather than cooperation.

I hate reverse incentives. I've decided that they are actually the first thing to be eliminated in order to have a healthy society because while you can't fix human nature, you can fix the consequences for actions to a degree. We're supposed to be good people at TOPP. We're supposed to care about others. We're supposed to do 110% of our dishes. Yet there are still dishes in the sink. So are we not good people? I don't think that's a fair assessment. Sometimes we're "too busy" to do dishes, which is a subject of human nature on which I can speak at length. But the point is there is no motivation to do 110% of our dishes so we don't do them. If all of the sudden dishes were checked out via RFID and there was a $1000 salary reduction for dishes unwashed, I don't think there would be dishes in the sink.

So I need a conclusion. I guess its something like, while doing too much design up front is bad, being "agile" -- by which I really mean, being sloppy and not thinking of consequences for the future -- is not only a poor practice for coding for the future, its also hurtful to others in that they have to clean up after you. I don't think programmers should be forced to be "application developers" nor that the role of "clean up" is somehow beneath "rock star" programming. But I do think, especially in an organization like TOPP, that programmers should have these options. And they should not be decided upon by one programmer dumping his "agile" work on another. Poor form, I say...poor form...