Let’s start with this: what does software quality mean? And more importantly how do you achieve quality and - yet more importantly - what level is worthwhile?

We’ll asymptotically approach answers to these questions and more in this week’s edition.
 

Pretty porcelain and twisted pipes

The crystallizing inspiration for this week’s newsletter was this tweet from sometimes-Pythonista David MacIver[0]:

In one sense I violently agree, and in another sense I think this is potentially horribly misleading. This is because the truth of this philosophy depends greatly on context, including what kind of software you’re talking about and the goals you’re trying to achieve with the software.

But to be clear, what MacIver is saying is that software design quality is not defined by the elegance of the code in toto or the beauty or the simplicity or even the readability, rather, these things only matter at the edges where people will interact with the code. The rest is only judged on whether it works or not, and perhaps further, whether we can know that it works or not.
 

Beautiful code

That’s a nice gotcha, because I want to mention briefly David Heinemeier Hansson, known as DHH, the creator of Ruby on Rails. DHH likes and promotes Ruby because of the beauty the language encourages and because programmer happiness - achieved at least in part through beautiful code - is an important virtue.

Why is beautiful code important? What does it do?

Well, it’s comforting to look at. It may inspire a programmer while working to continue honing their craft and maybe even writing less code (more code just means more potential bugs).

But what does it do for the running application? Nothing.

What does it do for the testability of the code? Maybe something…. depends.

What does it do for the maintainability of the code? Again, maybe something… maybe.
 

Library code vs. business code

The context of your code matters a lot. If it’s library code, like a standalone Django app, then I’d back MacIver’s design philosophy 100%.

You can have the equivalent of library code in your own Django site even if it’s not shared. We’re talking equivalency here. Some kind of stable code where other people (or you) are almost exclusively going to be interacting with and reading code at the interface level, then yeah, let’s call that library code.

Business code, in contrast, is what uses the library code, and is what’s likely to change. This is often the core business logic, it might even include a lot of the interface. Another speaker a Python conference referred to business code as “where the money is”.
 

The costs of working with gooey code

There’s no design loss suffered from having “gooey code”, code beyond the API that’s hacky - presuming it works in a tested fashion. However when we’re talking about what qualifies as business code, which is the overwhelming majority of every Django app, the API doesn’t serve as an impermeable layer.

You’ll find your team working throughout it, meaning that you need to be able to understand it, to modify it, and to test those modifications, and ugly hacks make this challenging.

These hacks may not, in stasis, make your application worse, but they add a significant cost to working with it. If your application is in stasis, then so be it! Really! But if you’re going to maintain your site this is a not-good-problem.
 

The part where we actually talk about quality and about Django

Okay, so what is software quality? And how do you achieve it? And is it worth it?

Well first off, does it do the primary thing it’s supposed to do? Is that measurable? And then does it meet secondary goals? If the primary goal is accurately pricing rare Beanie Babies, does it satisfy the secondary goal of being easily testable, that is, maintainable?

At the base of our “Maslow’s hierarchy of software quality” a program must satisfy some specific instrumental goals. Next it must meet secondary instrumental goals. And maybe tertiary instrumental goals. After this we get into territory about the software itself in a way that doesn’t involve the end customer, only the buyer and other programmers (potentially including “future you”).

These other goals may include general maintainability, testability, extendability, readability, elegant abstraction, etc. They’re not bad goals they just [usually] must follow the instrumental goals.

And so in a roundabout way, this week’s lesson: in a Django application (site) if you need to improve the quality of your design, and often the quality of both delivered software and collaborative medium, modeling it library software is a good way to start.

I don’t mean add a bunch of hacks. I mean take advantage of the defined interfaces - model methods, managers, forms, serializers, commands, and views, to create containers of “this is ugly but it works”. If nothing else Django provides lots of nice API boundaries even if it’s up to you and I to decide where to put code.

Start taking advantage of those boundaries.

Awfully hackishly yours,
Ben

[0] He’s the author of Hypothesis, a Python testing tool inspired by Haksell’s QuickCheck

More like this

• And now the reasons for moving Django models (This Old Pony #37)
• We didn't understand this old code so we just replaced it with a binary latrine (This Old Pony #35)