“We can do better” - NorikiTech
The CI pipeline takes an hour to run and it’s getting longer every month. There are five slightly different implementations of the same thing in the codebase. The docs for the network module were last updated two major versions ago. The project has a few thousand warnings. “It is what it is.”
The project you work on may not be as bad as this, but there are pockets of persistent inefficiency all around. Larger organizations have more of them simply because there are more cracks between domains of ownership. When you work alone, you’re authorized to make things better by default. When a hundred people and a dozen or more teams share a project, it becomes unclear who can change what (and to what extent). People start looking away: “It’s not what I’m supposed to work on. This will disrupt other people’s work.”
The team needs to be disciplined and conscious of creeping entropy to avoid this. Unchecked, the project naturally becomes a Big Ball of Mud as described by Brian Foote and Joseph Yoder in their 1997 article of the same name:
