== Code stability in my one Django web application We have [[one Django web application DjangoORMDesignPuzzleII]], a system for automating the handling of much of our new Unix account requests. It was started in early 2011 (using Django 1.2) and I did [[a retrospective DjangoAppRetrospective]] at the end of 2014 where I called it a faithful web app, one that had just kept on quietly working without problems. That's continued through to today; the app needs no routine attention, although every so often I tweak it to better handle an obscure situation. One of the interesting aspects of that quiet stability is the relative stability of the application's Python code over those nearly six years so far. There are web frameworks where in six years you'd need to significantly rework and restructure your code to deal with changing APIs and approaches. For us, Django hasn't been one of them. Although [[we're not quite current on Django versions DjangoUpdatePain]], we're not that far back, yet much of the code is basically the same (or literally the same) as it started out all those years ago. I'm pretty sure that almost all of our model and view code is untouched over that time, and I think a lot of our templates are untouched or only minorly changed. However, this is not a complete picture of code churn in our app, because there have been Django changes over that time in areas such as [[routing DjangoUrlReversingRepeatingMyself]], [[command argument processing DjangoMgmtCommandArgProblem]], [[template processing DjangoTimesinceNBSpaces]], and [[project structure ../programming/BadProjectLayout]]. These changes have forced code changes in the areas of our app that deal with such things (and the change in project structure eventually forced a massive renaming of files when we went to Django 1.9). While this sounds kind of bad, I've wound up considering all of them to be relatively peripheral. In a way, all of the code involved is plumbing and glue. None of it really touches the heart of our web application, which (for us) lives mostly in the models and views and somewhat in the core logic of the templates. Django has been very good about keeping that core code from needing any substantive changes. We still validate form submissions and generate views and process model data in basically the same way we did in 2011, and all of that is what I think of as the hard stuff. (Although I haven't measured, I think also it's most of the app's code by line count.) This code stability is one reason why Django upgrades have been [[somewhat painful DjangoUpdatePain]] but not deeply painful. If we'd needed major code restructuring, well, I'd probably have done it eventually because we might have had no choice, but we'd have likely updated Django versions more sporadically than we have so far. PS: Although Django is going from version 1.11 to version 2.0 in the next release, the Django people say that this shouldn't be any more of an upgrade than usual. And speaking of that. I should get working on updating us to 1.11, since security updates for 1.10 will end soon (if they haven't already).