a guide to software infrastructure

I looked at the calendar today - October 2007. I realize that I’ve now been out of school for the better part of 8 years now.

In that 8 years, I’ve come to realize that the term “software architecture” can mean a lot of things, but usually it means one - very specific thing.

“How do we create a programmer underclass that we can safely ignore?”

Again - it looks like other people have beaten me to this observation by several years.

Key points to note:

• Smart, experienced people become incompetent through loss of hands-on practice.
• Tasks that call for massive feedback divided among groups that communicate bureaucratically.
• The natural emergence of dynamic, creative design work squelched by remote idealists.
• A programmer underclass established.

The most interesting part of Eric’s four points is the last one - creating the underclass of programmers.

There’s a couple of techniques to create this upper class:

By far - the most common technique I’ve seen is to lean heavily on the belief that static languages provide enormous benefit to building correct programs. Second - you declare that “dynamic languages and unit testing is just so much bullshit”.

This does a couple things.

1. You confuse the audience into believing writing mathematical proofs has something to do with writing correct business application software
2. Since we have static compilation doing some marginal correctness verification in the form of type checking - programmers are free to get away with churning out code without any tests what-so-ever.

This is patently absurd. If type checking gave programs any kind of useful safety - you’d never see a NullPointer exception. You’d never see a type cast error. Nevermind that type checking can’t actually check that your code is logically correct. Type checking isn’t going to save you when someone just writes the wrong algorithm.

Next, the culture will try to push all quality control issues down to the department called “Q/A”. Now - if the team ever shipped code with obvious bugs to the Q/A group - one has to wonder what the hell all that type checking really bought us. What I wonder is how people justify wasting staffing people in Q/A departments when there is ample proof that the programmers are shipping crap.

Call me nutty - but if you really care about the quality of the code you ship - you start at the programmers. You start with them codifying a small informal proof - a unit test. You make sure that there is an integrated and continuous build system running a regression suite on every commit to source control. If you’re ambitious - you’ll make sure that there is code coverage analysis.

If you really care about quality - you do as the Japanese did when they wanted to have dramatic quality improvements. You do it continuously and you do it everywhere. Laying the responsibility for quality on just a few select individuals who happen to be in a group with the “QA” label isn’t just unfair - it’s just plain stupid.

Why am I rambling on about a practice that everyone already knows is the right thing to do?

Simply because most organizations do not know that it’s the right thing to do. Most organizations lack proper source control system, they lack proper mailing list software for communication and they lack proper bug and issue tracking software.

Things do not have to suck so badly.

Technorati Tags: software