Are there places where lower quality has less negative impact? Possibly. Except maybe on your soul.

First, Some References

Here are a few articles bearing on the topic of quality that I’d like to commend to your attention:

Mike Hill muses about how TDD helps by reducing mental scope.

Corey Haines riffs on going too far versus taking too much time, and asks how abstraction comes into the question.

Jeff Langr tells us about his experience “slamming out scripts”, and what he plans to do next time.

Then, My Point, If I Do Have One

What kind of work could we be doing where low quality doesn’t matter so much? Well, certainly, work that doesn’t matter, but that’s not very interesting to me as an example. I’m curious about whether there are languages, architectures, situations where quality reductions are less troublesome, or more troublesome.

I suspect that there are.

I’m used to writing systems that consist of rather a lot of interconnected code, and that are subject severe damage if we do it poorly, as in this picture from a previous article:

Horrible path through bad code

The skills involved in these systems include the ability to build decent abstractions, to identify cohesion and coupling and do something about them, and so on. These systems include substantial re-use if they are done well, at least of code within them. (That old “no duplication” thing.)

There are systems that seem, on their face, to be different from that. Consider a typical small Rails app.

The Rails app will start out with a bit of a central database, and a handful of pages that do things to it, fetching information, displaying, updating, and so on. The pages have some concepts in common but their code is mostly independent, as is the HTML that displays them. What commonality there is is mostly in the database.

Rails does a good job of letting us update the database and then rebuilding the pages to attach to the new database structure.

With an application like this, we can let the individual pages get a bit crappy, and it only affects that page. It is not likely to break the whole system.

Or Is It?

Except, of course, if the crappiness includes a little crappy logic that puts errors into the data. Of if the crappiness makes it hard to see the logic of the page and there is a way to break it. Or … come up with your own examples.

And Crap Doesn't Scale

Build twenty pages this way and they’ll ask you to change the format of all of them. Oops, I wish we had started using CSS back about page four.

Build twenty pages this way and you’ll see that you’re doing similar things over and over, in different ways, some of which are better than others … and some of which don’t work at all. You’ll start changing multiple pages just to change one. Oops, I wish we had built up a bit more of a library of useful functions.

Still, We Can Cut Corners For A While

Nonetheless, with generated code, and a strong framework, we can probably cut corners for a bit longer than we could if we were building code that is more subject to being all munged together.

For a while. For a while. Let your Rails app slide very long, though, and there you’ll be, working on another steaming pile of bad code.

And What About The Children?

To me – and I do mean to me – there’s a more important issue. I can’t work at my peak all the time. There are jobs that require incredible care, and jobs that require less care.

But in the end, it’s important to me to do good work. That’s what keeps me focused on learning how to do this, thinking about how to do this, writing about how to do this so that I’ll know what I think about how to do this.

If you care about doing good work, you’ll keep pushing forward.

If you don’t, get the hell off my lawn.