Django is the web framework for perfectionists with deadlines. Django is also what we use at Nelen & Schuurmans for all our web projects. Are we perfectionists? Do we have deadlines? I’m going to write down some thoughts on this. Mostly for myself, but it might be educating or thoughtprovoking or fun for others, too :-)
Deadlines? Yes, very much. It’s the end of the year and the end-of-year budget cut-offs are near. So everyone wants to get this or that done by the end of the year. Or at least pretty please invoice before the end of the year.
Yes, again. As a company, we can get things done quickly. We’re pretty agile. So if we were quick and flexible in the last project, perhaps we could do this little three-month-project by the end of next week? :-)
Another reason: estimating is hard. But most projects are still a fixed amount of cash for an extimated fixed amount of work by a fixed end date. The end date often remains standing (and likewise the amount of cash) and so there’s a scramble to get the impossible done by that time. So: deadline :-)
The impossible we do on schedule. Breaking laws of nature takes a bit more time.
Perfectionists? I mostly view that from a software engineering standpoint. Some solid software engineering quality aspects we do more or less:
Checking javascript syntax all the time in Hudson.
Testing and code coverage.
Actually working software and happy customers.
Documentation.
Deadline or not: hudson says your project is fully broken if jslint finds one syntax error in your javascript files. Reason? Deadline or not, internet explorer is extremely/rightfully picky about javascript syntax and most customers use internet explorer, still. Deadline or not, the project has to actually work. There’s no room for not being a perfectionist.
A bit less documentation doesn’t actively kill your project. Documentation has to be good, but it can wait a week if needed. There are other tools besides deadlines to get the documentation up to scratch: automatic generation of all documentation in a place where the customer can see it. Or releasing projects on pypi: that tends to make sure that I update the README.txt to a usable state! :-)
Harder calls: what’s the code coverage that you accept when faced with a deadline? The perfectionist in me screams for 97% code coverage everywhere. The deadline screams for less in those parts of the code that are regularly executed during day-to-day use of the site and that are quite simple to implement. So: the deadline only wants tests in the hard parts. And not in the quick custom hacks to get the generic product working for this specific customer.
On the other hand: by postponing automated tests, you’re building up technical debt.
Now this is where django comes in. To me, a django project consists of one site and several applications. That’s a real handy way to restrict the damage that a deadline can do to your technical debt:
The site contains the quick hacks and how-should-we-implement-this and what-does-the-customer-actually-want code.
The applications are use in multiple sites and have to be good and well-tested.
Is that split something that’s useful? Dangerous? Helpful?
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):