Summary
This may come as no surprise, but we deliver crap. Why this is so has been bothering me for a decade. Maybe this is why.

It is a premise of mine that nobody who develops largish systems should ever be anything but embarrassed. Our (that is, the industry's) track record in delivering systems is pretty abysmal. Late, over budget, buggy systems is the norm. To be clear I'm not talking about little bitty 100k LOC guys, I'm talking about 1M+ LOC systems that are expected to have very long lifetimes. You can disagree with this premise all you like but I think the evidence is on my side.

I constantly think about this. Constantly. I have been, for about 10 years or so, trying to understand why it's so hard to build quality systems. I've tried lots of things; tools, processes, languages to make things better. Or at least appear better to me. Unquestionably some things have been enormously helpful. Java was, in my mind, an enormous leap in popularizing useful things like GC and OOP (well sort of. OOP today is crap, but that's a different story). Language aware IDEs like IntelliJ and Eclipse have, at least for me, dramatically changed how I talk to my code. For the better I think. Nevertheless I routinely feel unsatisfied with how things are. Incomplete or something. I dunno. Just not right.

This morning while watching the sun rise and contemplating some recent circumstances I've been dealing with I realized why the state of developing systems is the way it is. The name for my pain is...Managers.

Before you tune out, or nod your head in vigorous agreement, this is not a "Managers Are All Idiots" diatribe. On the contrary, I've found most of the professional managers I've worked with to be well intentioned, reasonably intelligent people. To be sure some I've worked with and for some that have been horrifically stupid (<= carefully chosen word) but then I can say the same thing about some developers. No, it's not that I've decided that managers are stupid. They're not. They're children. This is what I realized with my coffee. Thank you Peets.

Most of the managers I've worked with made a conscious decision to track on the management career path roughly because they were interested in it. (I have no idea why anyone wants to herd cats for a living, but evidently some do and that's ok I guess.) I don't know of many development managers who weren't code jockeys for a little while. Sometime in their early 30s though they started on the management track. This is the crux of the problem I think.

In my early 30s I was, like a lot of developers I know and have and do work with, annoyingly cocky. I was confident I knew how to write software correctly and, I'm now very embarrassed to say, there was not a lot that someone could tell me about writing software. This is exactly the time when many managers decide to become managers. And now their software world view ossifies with this sort of cockiness, this know it all, it's not that hard, perspective built in.

So when I now go to a manager and attempt to explain that the coupling in the system is going to crush us in a year or so unless we take steps to address it now, their world view doesn't include a perspective that let's them say "Oh right. I remember making this mistake.". They can only recall that in their short developer lives simple code hygiene was never really an issue. (As a side note I giggle, absolutely fucking giggle, when I see job postings for senior(?!?) software engineers with 7+ years experience. 7 years. Senior. What's a Junior engineer? 30 days and read a book? Busts me up.) This means that getting this sort of work into the list of tasks is never really with these manager types full buy in. When push comes to shove this kind work is always dropped off of the schedule (sprint list, whatever) because the folks who decide what's on the task list don't have any basis for valuing it. They can see the value of features and functions, but decoupling the system is not something you really value until you've felt the pain of not actively doing it.

I think there is some element of truth in this new perspective of mine. Managers should not be managers until they've written code for something like 20 years or so. They shouldn't be deciding things that they have no real experience in. Of course nothing is going to change. Not yet. Frankly I think we'll continue to develop systems the same way, and deliver the same crappy results, until some Titanic sort of event occurs. I don't know what it will be but, eventually, certainly, we're going to kill a lot of people, or put a large number of people into the poor house overnight or some equally human outcome. I'm not talking about the annoyance of some Outlook worm that brings your network to it's knees. That's really an efficiency issue. Eventually our hubris, our lackadaisical attitudes will catch up and people are going to be seriously and righteously pissed off. That's when the manager inversion will be corrected. It won't be features, it will be correctness that drives and to do that managers will have to know correct from a hole in the ground. Too bad we'll wait so long.

Talk Back!

Have an opinion? Readers have already posted 34 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