Field guide Plate 02
Django & Python
The framework underneath nearly everything I build. Applications from an empty repository, features added to one that already has users, and the data modelling decisions that are cheap to make early and expensive to change later.
— the core of most of my work
I
Where it’s found
who this is for
You are starting something
and want the first six months of decisions made by someone who has watched a few of them go wrong. Most of what makes an application painful later is settled in the first fortnight.
You have an application
with real users, and adding to it has started to feel risky. Usually that is a data model that no longer matches what the business does, rather than bad code.
It has become slow
as the data grew. Almost always the ORM issuing far more queries than anyone realised, and almost always fixable without the rewrite somebody has proposed.
II
Field marks
what the work actually is
Data modelling
Models that match what the business actually does, with the migration path thought through. This is the part that is cheap now and expensive in a year.
Application features
Views, forms, permissions, background jobs, admin. The unglamorous middle of an application, done so the next person can read it.
REST APIs
Django REST Framework, versioned, documented, and authenticated properly — whether the consumer is your own frontend or someone else’s system.
Query and performance work
Finding the N+1s, adding the indexes that matter, and caching only where measurement says to. Numbers before and after, not adjectives.
Tests that get run
Enough coverage on the paths that would cost money if they broke, running in CI. A suite nobody trusts is worse than none — it teaches the team to ignore red.
III
Behaviour
how it runs
-
01Read first
Existing code and existing data before any proposal. Data tells the truth about how a system is used.
-
02Scope
A written plan with an order and the reasoning for that order.
-
03Build in the open
Small branches, deployed somewhere you can click on every few days.
-
04Hand over
Documented in the repository. You should not need me afterwards.
IV
What it costs
what decides the price
Scope decides it, and on an existing codebase the state of that codebase decides it as much as the feature list does. A well-tested application takes changes cheaply; one without tests charges you for the caution.
Defined pieces of work are quoted fixed. Anything open-ended starts with a short paid look at the code, producing a written plan and a fixed number for the rest — the plan is yours either way.
V
Questions
the ones I get asked
- Do we need a rewrite?
- Almost never, and I will usually argue against it. A rewrite spends the whole budget getting back to where you already are. What normally helps is fixing the two or three places the model has drifted from the business, which is a fraction of the cost.
- Can you work with our existing team?
- Yes, and often that is the arrangement — I take the piece nobody has the time or the specific experience for, in your repository, following your conventions rather than importing mine.
- What about Python versions?
- Old Pythons and old Djangos are routine. The upgrade is usually a known quantity; what makes it slow is dependencies pinned to versions that were never going to move, and that is worth finding out early.
Send a note
Tell me what you have, what is wrong, and what it should do instead. I will tell you honestly whether I am the right fit.