If you’re not familiar with Hacker News then much of this satire may go over your head. Suffice to say it’s an Internet forum for software developers and entrepreneurs that tends to devolve into self-parodying echo chamber[0].

 

We didn’t understand this old building so we just ripped it down and replaced it with a latrine.

That was the line that got me (it’s article number 8 above).

Of course it’s a beautiful zinger with regard to many a Hacker News post, but it gets to the hear how people respond to even just-slightly older software projects. I alluded to this in a previous email about the influence of legibility bias[1] with a quote from an old Joel on Software blog post:

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

I want something I understand, I understand X, let’s do this following X. Even if X is a means that has nothing to do with the ends… which it doesn’t satisfy anyhow.

Now, this is funny because a builder wouldn’t do this, or at least if they did it would not be the expected course of action. This might be because the profession is older, by at least few thousand years, or it could be because both the costs and benefits of the project are more tangible and intuitively understood.

The former is true, but the latter feels more persuasive to me.
 

What does this look like in Django apps?

As a general rule, code that’s incredibly inelegant usually looks unjustifiable on its own. And, frankly, in most cases, it is.

In a Django app it’ll look like some horribly complicated collection of nested iterations with various accumulators. Which can be replaced with a single queryset method that pushes the work to the [more efficient] database, e.g. a queryset filtering on an aggregated value.

It could also be seemingly duplicated code like model and view methods.

Or it could be an entire project. “Wouldn’t it be better to just start over?”

Why is such code there? Often developer expediency. The original developers may not have had the familiarity with or time to become familiar with framework or language features. It could also be a lack of such features - Django’s queryset-level aggregation support has improved much over the years. Or they may not have understood the benefits and tradeoffs of different features and sub-systems.

Sometimes, though, there are other reasons that don’t reveal themselves on the surface. Maybe what looks like an ugly iteration-based hack is actually critical because of some subtle difference in how a value in conditionally aggregated.
 

What difference does this make - and how do you solve for it?

The real world cost of needlessly tearing down a building and replacing it with something smaller, and less fitting, and - and - stinkier, is readily apparent.

With software it’s not obvious. We don’t inhabit the software we build - VR still isn’t that good. Instead the costs are hidden, lost features, usage paths gone we didn’t know about.

The way you learn about this before hand is by stalking your users. Okay, stalking is a bit much. But querying them, directly and indirectly - do they use feature Z? What do they use it for? Why do they need to do that? In the absence of direct questioning remote metrics can answer 60-80% of what you want to know, enough to make reasonable informed decisions.

Maybe that janky looking code really can be blown away and replaced by something far simpler, faster, and easier to maintain.

Or perhaps there’s one required value that a few users need that isn’t sensibly computed outside of a plate of Python spaghetti.

And what of more significant things like modules and entire projects or sites? The recommendation to query human beings still stands. From there the goal is to refactor into comprehensible, maintainable code.
 

Links for this week

Going to try something new this week and include a few links worth sharing.

• Django security releases issued: 2.0.2 and 1.11.10 the auth.forms.AuthenticationForm can leak information under certain circumstances about whether a user is active or not
• When to Use MongoDB with Django (don’t do it) As I’m on the lookout I’ll start collecting more for next week.

Without clever salutation,
Ben

[0] https://news.ycombinator.com/
[1] It’s faster to write from scratch, but riskier : the software architecture and urban planning issue (This Old Pony #29)

More like this

• Crunchy on the outside, gooey on the inside - your Django project code, that is (This Old Pony #36)
• Two reasons why software gets complicated - even Django sites (This Old Pony #34)