title: ‘Bad Architecture (This Old Pony #76)’ layout: newsletter published: true date: ‘2019-01-23T11:01:00.000Z’

We’ve been looking at why people erroneously think they’ve reached the limits of their software stack:

Both generally and with regard to Django, in most of the cases where I’ve seen _ people who think they’ve reached the limits of what their tools can do, they’re simply wrong, often by significant margins _. The reasons, though, vary a lot. They’re interesting in and of themselves but identifying them is important unless you have piles of cash to turn and don’t mind risking your entire software stack.

This week we’re going to look at “sub optimal” architecture in Django apps and the problems it causes. Just like the refrain from that classic rock hit[0]:

Bad software architecture
And I can’t deny
Bad software architecture
Till the day I die, oh
Till the day I die
Till the day I die


What I mean by architecture

There are fairly specific definitions for things like “software architecture” and “systems architecture” but here I’m going to use it a bit more generally.

What we’re talking about it the design of the parts and how they interact. For a web application it’s fair to include higher level “architectures” like the relationship of the services you’re running, from the application server running Django to the web server, databases, task queue, etc. This also includes lower level “architectures” like how [Django] apps are structured, and even the interfaces available within the application for sharing or updating data (including middleware, template context processors, etc., etc., etc.).

If at any point you feel like substituting “design decisions” for “architecture” feel free.

What architectural problems look like

It’s story time, and I’m going to tell you about the worst architecture I ever created.

We started on what was supposed to be a fairly small project that the client originally described as a “pretty much just a database”. It just needed some facility to fetch data from a third-party service and then update the data locally with a dashboard for admin users.

Actually, it was an applicant tracking system (ATS) for managing assessment workflows for multinational HR departments that would use web services to integrate with a number of third-party assessment providers and then allow the client to create custom scored reports for each candidate.

Here’s what we didn’t know at the very beginning:

You won’t win a race in a Porsche if you leave the parking brake engaged[2].

Over-architectedly yours,


[0] Slightly modified, from Bad Company’s song Bad Company from their album called Bad Company (remember, naming is hard)
[1] Does agile solve for this? I think the answer is “it depends”. Agile (TM) probably can’t, but *agile* closer to the original manifesto will help. Ultimately if your target shifts you’re still going to have to backtrack, the hope is that your methodology reduces the need for backtracking, at least w/r/t latent requirements.
[2] Maybe. Years later the application above is still alive. It was a success, as far as the client and their customers were concerned. I’d tend to think it’d have been a bigger success and quicker given the alternative to some of the questionable choices enumerated above, but working software is working software. ¯_(ツ)_/¯