Week 6. Still finding things.
I didn’t build this application. I inherited it about six weeks ago. My job is to maintain it, handle tickets, develop new features, and manage the relationship between business and IT.
What nobody told me is that a big part of the job would be understanding why things are the way they are — and quietly realising that some of it probably shouldn’t exist.
The first thing that stopped me
There’s a module built with 6 crossed dimensions. It was designed to handle forecast overrides — letting users manually adjust the calculated forecast at a very granular level.
Sounds reasonable. Forecast overrides are a legitimate need in demand planning.
Except when I first saw it, my reaction was simple : this is scary.
Not because it’s wrong. But because in Anaplan, crossing dimensions isn’t free. Every additional dimension multiplies the size of the module — not linearly, exponentially. 6 crossed dimensions means the model is holding a structure orders of magnitude larger than it needs to be. Every calculation that touches it carries that weight. Every new feature built around it inherits that complexity.
And that complexity is permanent. It doesn’t go away when you move on to the next ticket.
What happens when the backlog keeps growing
Here’s the real problem I’m facing now.
The application has a backlog of over 100 tickets. Business users keep submitting requests — new features, new filters, new conditions. Some are legitimate. Most are submitted without anyone asking whether the system can actually absorb them.
And the team responsible for this model is the same team managing several other applications.
So every new feature added to an already saturated model costs more than it should. Not because the feature is complex. Because the foundation underneath is already carrying too much.
I raised this. Officially, in a meeting, with a concrete example. The reaction was : “that’s scary.”
Not : “let’s fix the foundation.”
Just : “that’s scary.”
And the new feature requests kept coming.
What I think should happen — but rarely does
Before adding anything to a model like this, someone needs to ask a different question. Not “can we build this?” but “can the system structurally absorb this without degrading further?”
That question almost never makes it into the conversation. Business priority, deadlines, and delivery pressure take over. The system gets heavier. Delivery gets slower. And everyone wonders why.
I don’t have a clean solution yet. Restructuring a live application with 100 pending tickets and active users isn’t something you do overnight.
But I’m documenting what I see. Because I think this is how most application bloat actually happens — not through bad intentions, not through laziness, but through a series of reasonable-sounding decisions that nobody ever stopped to question.
The model remembers every decision ever made in it.
👉🏼 The model remembers every decision ever made in it.