I Built His Cage

Wednesday’s post on David Platt’s “Why Software Sucks” touched on many symptoms of crappy software. Bad UI and security gaffes are one thing. It is quite another to visit these systems as they’re growing in the womb.

I’m talking about the development process itself. Is there something fundamentally wrong with the way software is developed?

At work, our system’s second release, which is an agile project that has been under development for over a year, has suffered its second release delay due to last-minute bugs. And this is a team in the company that is the model agile team for all the others.

(warning: software ahead)

This delay has left me with some idle time, with sporadic spurts of work. Once a upon a day this week, I was writing a unit test, and I needed to know the allowed values of a certain string field. All the information I had was a getter and a setter. If I had written the class, at least some validation in the setter would have blatantly given it away. Instead, I had to bug one of my coworkers to find out.

Now, I knew that this was not a domain-driven project. It is “service-oriented” (which it is not, but I’m saving that for later). So I kind of expect weak domain objects. It turns out, the problem ran deeper. I basically got my coworker to admit that the rule is not in the object because someone consciously does the validity check in the database layer!

So if you ask me, a self-described domain-driven design practitioner, why software sucks, it is due to weak design; namely, weak domain layers, and in some cases, a surprising misunderstanding of layered architecture itself.

(that’s how I understood it — am I still just a naive college kid?)

Rick Kitts’ article, titled I Know Why Software Sucks, takes a look at the development process itself, and aims higher than I do: management. The crux of the post can be summarized thusly:

… 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.”…

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.

… 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.

Lordy oh Lord, was this ever the attitude on The Project? While it certainly was similar, Kitts is talking about developers becoming managers. On The Project, my pointy-haired boss was never a developer, despite claiming to hold a computer science degree. Sometimes when I think back on how I was able to accomplish what I did there, I come up empty.

(yyyyeahhh)

I think 20 years of development is a bit extreme, but Kitts is right on the money here. In too many interviews, the interviewers prodded me on how I should aspire for high management. My answer was always “maybe a project manager, but only after having been an architect.”

I have always warned myself against floating too high into the stratosphere and away from the technical stuff, the actual writing of code. I certainly can’t imagine being an architect who doesn’t code.

I don’t see how one can be taken seriously when lecturing developers on his brilliant multi-tier architecture made of mere boxes and arrows when development realities point to a desperate quagmire of coupling and brittleness.

My goal right now is to amass several years as a developer, in order to become a technical lead on whatever team I am on at the time. From there, I’d like to step up to whatever position that entails making major design decisions.

From there, I wouldn’t be opposed to a step up to architect, but the altitude would have to be right — I would want to reserve the right to do development work on the system I’d be architecting.

(if I were her, I’d demand the right to pound the nails into the wood)

Kitts also echoes a prediction that my sometimes-senile senior project professor warned us with:

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 agree with both of them.

There is a persistent under-estimation of how complex even simple systems, like The Project, really are. People have to remember that software is nothing. Software is whatever you want to make it.

This freedom makes it fundamentally different from any other engineering discipline. The attitude that software is “soft” and therefore cheap to change is a fallacy (unless you’ve paid off your technical debt) and is a direct contributor to the sorry state of the industry today.

Somehow, someway, we need to make this query return more rows:

> SELECT * FROM Managers WHERE Managers.clue > 0
0 record(s) returned.