I had a conversation with a developer who built a simple single-vendor e-commerce store but ignored many Django guidelines. My argument was that if you are disregarding a framework’s architecture and best practices to implement your own custom solutions, then it would be better to create your own framework instead.
He completely modified Django’s folder structure, which is unnecessary for such a simple project. Moreover, he installed unnecessary packages like django-crispy-forms despite using Tailwind and django-phonenumber-field just for phone number validation. He also heavily customized Django’s admin panel to serve as the main dashboard, which I believe is not recommended by Django—or am I wrong?
Despite taking almost a year to build this project, it is still buggy, missing key features, and not production-ready. Even after all this, he continues to justify his approach. Is my perspective on this correct, or am I missing something?
I want to mention two things:
i am not going to maintain the project.
yeah i am talking about the good practices while using a framework
The list of things you mention are a mixed bag - sharing my opinion on each in order…
I know a lot of people who have done this to various degrees. In most cases you are simply making things harder for yourself .
(I have generally found that the desire to do this comes from having familiarity with other frameworks or languages, or books, blogs, videos, teachers, etc who are training principles based on those frameworks and languages, and end up believing that how those other environments work is “the way” to do things.)
These don’t necessarily “compete” with each other. Now, I don’t use Tailwind so I don’t have any specifics, but I am aware of the crispy-tailwind package designed for the integration of the two.
Seems like a potential “underutilization” of the package, but I’m not sure I’d necessarily define this as “wrong”.
If this justification is based on relevent facts (relevent to Python and Django and not misapplied from other frameworks and languges), then there may be reason to do it.
However, if there’s anything I’ve learned across more than 45 years of developing software, it’s a concept that I’ve simplified as “Don’t fight the framework”. Software development is always easier when you change your mindset to work with the tools (libraries, etc) available to you. What you don’t want to do is try to alter the tools to match your mindset and biases that you’ve acquired from working with other tools.
While I completely agree with Ken about going with the flow of a framework and not fighting it, I also want to be a little more cautious.
It’s impossible to tell from your post whether any of the changes are proportionate or reasonable.
This could involve many levels of complexity - we can’t tell how simple or complex it actually is.
But we can’t tell exactly how much he modified it or why (your screenshot tells us little). I’ve seen lots of slight variations on the default Django structure - I suspect few people change nothing at all.
e.g. I’ll put the project’s settings.py, urls.py etc within a config folder. And I like to put all the apps within an apps folder. This makes more sense to me than the default structure, and I’ve seen others do similar, but maybe it would outrage you?
Yes, that’s what that app is mostly for. Unless you think validating a phone number is nothing more than “check it’s all numbers” I’m not clear what your objection is.
Yes that sounds bad, but (a) that doesn’t necessarily have any relation to changing the project’s structure from the default and (b) we have no idea how much time over a year they’ve put into it, or what the expected timeline was.
You’re clearly upset about the state of the project and looking for validation. But other than a general “going with the flow of a framework is good” sentiment it’s impossible for anyone here to criticise the specific decisions on this project, given the information we have,
