“Leverage” is one of my all time favorite business jargon words. “We’re going to leverage an ECM system” = “We’re going to use use a database for files” but the former gets you much further in a conference room full of bored middle management.

More prosaically, leverage means amplifying force over a fulcrum as below.

It’s a wonderful analogy for non-physical processes as well, including in software projects, like Django sites. Today I want to examine just a few points in both the Django code of your project and the development process itself that work as leverage points.
 

In Django projects

Number one is querysets. Querysets, querysets, querysets, querysets, querysets, ad infinitum! We might just offer a separate service, “QuerySets as a Service”. Just stopping here would be sufficient.

A great deal of complexity and performance problems alike stem from poor or insufficient use of QuerySets in the Django ORM. The complexity comes in the form of gigantic view functions or methods, ad hoc querysets which are easily copied and pasted - wrongly, not to mention less testable code. The performance hits often come from data manipulation of one kind or another that could and should be pushed to the database but is instead punted to Python code or, worse, to yet additional queries. Organizing querysets into fat managers and taking advantage of advanced querying (as well as update patterns) in querysets so often results in significant organizational, testing, and performance benefits that code-wise it should be the first lever you look for.

Number two is logging. Logging isn’t a terribly exciting topic but having logs of actions and events, both user and system initiated, is one of the most reliable ways of debugging problems after they’ve happened, and identifying them before they happen. For such a seemingly simple task there are a lot of decision points in implementing a workable logging strategy. However any starting point is a good one, and it’s easier to deal with too many logs than with too few.
 

The development process

The number one process lever is automation. What to automate? Everything. Tests, deployment, local development.

Automating things means that your team doesn’t have to remember how to do things just exactly so, or even to do them at all. It’s free labor (at or to a certain point, at least!) and it’s a whole bunch of decisions that you only have to make once. Automation frees you to do other things and ensure that what you’ve automated is done better than it otherwise would have been (because it’s executed consistently, but read on….)

There is a downside to automation, which I think can be a hidden benefit, if you listen to the sound of grinding gears. Automating a process doesn’t improve the process per se. Automating a bad process just makes it happen… automatically[0]. But if you observe, then you’ll find that automating a process makes it explicit and this is what should allow you to see a bad process and then correct it.

The second lever is open sourcing modules. Like leverage in the financial sense, this can hurt you, too. It takes work just to make a module ready to be open sourced, and in the event people are interested in it it takes work to respond to them and manage the project. But in most cases you’re left with one of two outcomes. It’s not very popular so there is little management to do, but you gain the benefit of improved modularity and self-imposed code quality. And the other is that it is reasonably popular and other people contribute to identify problems and add features. Not everything nor everyone benefits from open sourcing, but as a lever it can be quite handy.

Mechanically yours,
Ben

[0] This is a common failure in business process engineering and management consulting more generally

More like this

• Turning around a Django site without a single line of Python (This Old Pony #68)
• The Django checklist manifesto (This Old Pony #66)