> Last time I looked a lot of the insides were terrible.
But is it really? Speaking from personal experience it is easy to compare project with large featureset (and one with heritage) to one with scope on doing single thing and come with conclusion that smaller, focused codebase is more consistent and better implemented. At the end of day what matters is if those terriblenesses actually bite back:
- is this code changed frequently? Does it need to be changed frequently?
- is it written in a way that that makes fixes and improvement unbearably costful?
- is it written in way that allows it to be put apart? How costful are those individual parts to improve?
Django is large codebase that is worked on by different people and when time permits this, which means different parts differ in their age, practices, and ultimately, quiality. This eventually results in codebase that may give appearance of being messy.
Joel Spolsky explains this nicely in his article about old and large codebases appearing as hairy and messy to developers:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Especially the part that follows below quote is valuable wisdom to keep in mind:
> When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.