Summary
"... when you have eliminated the impossible, whatever remains, however improbable, must be the truth..."

I've been hacking on the typesystem for this pretty cool language used in our applications. It's a little gnarly and you really want to keep your eyes on the road while you're moving bits around down there. Anyway I add my featurey thing, run some tests (passed) and checked in. Our poor test harness is having some growth issues these days and that leads to some pretty long latencies between a checkin and test failure alerts. So about 3 hours after I checked in I get the first of what would be many test-break mails. 248 broken tests. Uh-oh. Another mail. 1187 broken tests.

Actually this was promising. Test break records are rare these days and to get one you have to break something pretty fundamental and I was hopeful. In the end though I didn't even come close to a record, breaking a measly 11,000 tests. I had no idea why though and without the pride of a record to motivate me, figuring it out was going to be just another day of tree-traversal development.

Keep in mind it's been 3 hours since I checked in so I'm on a whole different thought train. Now I have to stop what I'm doing and start traversing up the tree to figure out what happened and how to fix it. This is even more frustrating because, as I mentioned, I did run some tests, both the new ones for the featurey thing and the ones that I concluded were relevant to the code I touched. And the test harness is telling me I broke things hell-and-gone away from where I was chopping up the code. It's kind of like putting a nail in the wall of your house to hang up a picture and having your car burst into flame in the driveway because of it.

(I should mention that the cause of the break wasn't actually in code we ship, it was because of some test harness code that, I argue, was not as well considered as it could have been. So it wasn't that tests were breaking so much as testing was breaking.)

These sorts of things that could broadly be classified as unexpected work are coming up with some regularity these days and I was complaining about it, as you do, while me and several folks from the crew I'm on were heading out to lunch at an entirely mediocre deli. The root of the complaint was, "Why?". "Why are we seeing an increasing rate of unexpected work?". Dark matter. Call it what you will, it sucks. It sucks your will to live. This tree search way of working gets tiring in a hurry. If you've been doing this for even a short while you know what I mean. How absolutely draining and demoralizing it is. How much it makes life, inside and outside of work, truly suck.

You know, you hit another problem you weren't expecting, you traverse back up the tree, sit back in your chair, maybe take a deep breath, and stare at the screen for a few minutes because, now, with so many traversals these days, it takes a real act of will to go deal with whatever it is that's suddently, annoyingily, in your way. This despite the fact that you're going to fall behind in your current task, which is already behind because of unexpected work during your previous task and you should get on this right now. And, if you love coding, really dig putting things together, you take that sighing resignation home with you when you stop typing for the day. How could you not?

So why? I've been doing this for a little while now and, though I've asked the question many times I don't think I've ever come up with the answer. Probably because there is no silver bullet. But I think the core cause is pretty apparent. Time. Time and pressure. We're required to make commitments to dates with so little information that the commitments are meaningless. But they're made and being professionals, more or less, we try hard to stick to them. At the expense of quality, which is really just an indirect way of also saying at the expense of the quality of life of developers. Because if you're like me you stress bad when you know you're throwing code around too quickly too often.

This is an old, old, old story and complaint. And spare me, please, the cry of XP! XP is fine when you have 2, 5, even 10 folks hacking on code for oneish customer and the reqs are reasonably solid and well understood. But if you have 50 developers writing code for customers literally around the world that is to be consumed by 100's of other developers XP just don't work. Indeed I think it's probably exactly the wrong sort of process to use. But that's another post.

Nevertheless, what to do? Ultimately I think the answer is that two possible things can happen. First, change how this sort of software get's sold. For whatever reason the software sales guys seem hard pressed to sell what's in the box. Rather they sell the next version or, perhaps more correctly, what might be in the next version. Or so it seems to me, I'm not a sales type. Second, change how this sort of software gets purchased. It seems that the purchasers are entirely inclined to suicide. It appears, as best as I can discern, that these folks would rather have software that does N things only marginally well on a particular date rather than N-X features that work reasonably well on the same date and then get X features at a later time. This despite the fact that they really aren't even in a position to consume N features because their developers are dealing with their load of unexpected work. It's truly insane. But changing people is either hard or impossible so I'm not holding out much hope.

You'll notice I don't talk about anything I should do. I don't think there's anything I can do. I have, with the very best of intentions, tried most everything. Top down, structured, UML, XP, C, C++, Java. Given those "in my professional opinion" type warnings about quality and TCO. And I do mean best of intentions. I've given it my very best shot for years and years and still I end up in circumstances where I'm not comfortable with the product of my labor because, again, I don't seem to have the time. In all fairness I'm not a great developer, something I think I can say because I have worked and do work with great developers. Those 10x more productive types. But, with no undo hubris, I'm not a suck developer either. So let's call me competent. And committed. If I'm both of these things and I've given it my best shot at crafting long lived software that doesn't require me to kill myself with quick fix rescue efforts to ship on time and failed, what am I to conclude? Seriously. What?

Talk Back!

Have an opinion? Readers have already posted 8 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Rick Kitts adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger