Large systems are usually plagued by problems that come from scale itself. Odoo handles this well, but it still takes a good deal of attention on our side. Every bit of neglect in how you design a workflow or the technical solution of a module gets stored away as technical debt. And it grows. We promise ourselves we'll fix it next time, but that's not true. In this post I'll focus specifically on custom modules - that's where this mechanism is most visible.
Odoo module development - how many modules is too many?
The scale problem shows up everywhere. Including in Odoo software development - in so-called custom modules. Odoo's standard features - even though they let you do an awful lot - stop being enough pretty quickly (or someone didn't know about the standard functionality and bolted on their own code... the horror!) - and that's when your codebase starts growing. And it usually grows fast. Which brings up the question - what's the best way to approach writing custom modules? I'm not talking about modules sold on apps.odoo.com here, but dedicated ones. How do you handle that?
The problem
If we go with the approach that it's better to build many modules, the connections between them quickly become so tangled that I feel for whoever has to upgrade it to the next version. One big module, on the other hand, brings back the problem of parallelizing work. The sweet spot has to be somewhere in between. It seems to me it takes a feel for the situation to know what's worth splitting off and what should stay together.
I had a situation where one module was responsible for several different pieces of functionality:
- Extended Odoo's sales module
- Extended the creation of a Manufacturing Order from a Sales Order
- Defined a new model responsible for uploading files to S3
The first two points could be called complementary, but the third was a completely separate piece of functionality. It was still fairly tightly coupled to the rest of the module's code, though, because that was easier at the time. About a year later, the moment came when the module handling S3 communication had to be split out. Another, newly built module also needed to use S3.
Splitting out the S3 module wasn't brutally hard, but in an ERP system that runs the whole company, that's risky - something can go wrong. The total time spent on the implementation plus the later split ended up being more than if someone had just split it out from the start. Of course, you can't always predict everything, though in this particular case - I think you could have.
What are the most common "bugs" I see?
- Missing dependencies in the manifest
- One piece of functionality split across several modules - and none of them actually works on its own
- Several different pieces of functionality crammed into one module
- A new module that conditionally changes behavior without accounting for all scenarios
Why does this happen
Cases vary a lot, and I never assume I know why someone did something one way and not another. Looking at code, I never assume a bug or problem comes from a developer's incompetence. I lean more toward thinking the code was written under time pressure, because the functionality had to ship fast. Sometimes AI gets thrown into the mix too - it can break something, or just as easily bolt on way more code than necessary, but that's a topic for its own post. Still, it's worth spending a few minutes thinking about how our code decisions will affect the possible development paths for our modules.
And this is important - if we don't spend a few extra hours on the code now, those "savings" will pay off later. Just not in our favor.
If you've had similar experiences with Odoo modules, or you disagree with this approach - reach out, I'd be glad to discuss it.