▲ | citizenpaul 10 days ago | ||||||||||||||||
I'm not sure the author or most people that write these types of academic theory papers ever really see actual ball-of-mud-spaghetti code in real world scenarios. I think anyone that thinks mudball is OK because business is messy has never seen true mudball code. I've had to walk out of potential work because after looking at what they had I simply had to tell them I cannot help you, you need a team and probably at minimum a year to make any meaningful progress. That is what mudballs leads to. What this paper describes is competent work that is pushed too quickly for cleaning rough edges but has some sort of structure. I've seen mudballs that required 6-12 months just to do discovery of all the pieces and parts. Hundreds of different version of things no central source control, different deployment techniques depending on the person that coded it even within the same project. | |||||||||||||||||
▲ | Swizec 10 days ago | parent [-] | ||||||||||||||||
> I think anyone that thinks mudball is OK because business is messy has never seen true mudball code. I’ve seen and created some pretty bad stuff. Point is not that it’s okay, but that that’s the job: managing, extending, and fixing the mess. Yes a perfect codebase would be great, but the code is not perfect and there’s a job to do. You’re not gonna rebuild all of San Francisco just to upgrade the plumbing on one street. Much of engineering is about building systems to keep the mess manageable, the errors contained, etc. And you have to do that while keeping the system running. | |||||||||||||||||
|