Reference: http://www.laputan.org/mud/<p>Among the companies that you've been part of,which one had Big Ball of Mud Architecture?<p>According to you what were the contributing factors?<p>If you don't mind,tell your years of experience in the answer
>According to you what were the contributing factors?<p>1. Inconsistent project-based funding model that leads to churn and a series of short-lived teams working on stepwise project deliverables, and little opportunity for consistent ownership of tech debt.<p>2. Micro-services that reflect poorly chosen boundaries (ie. project deliverables / team boundaries) rather than being based around well thought out domain aggregates. I guess this is Conway's law in action.<p>3. Resume driven development. People love to learn on the job, and like playing with and learning about the next shiny tech stack, but if everyone is doing that, it means that we're always building things on a stack we barely understand. I get it, the FOMO is real, but there's a lot to be said for simple, mature, well understood stacks even if they're not trendy.
8 YoE<p>Everywhere I’ve worked has struggled with what has been mentioned here as “resume driven development.” I love that term. Never heard it before. There’s always something “weird” about the stack, for example C#, React… and Neo4j for this one little thing. I guess if it makes sense, it makes sense, but certainly there’s a penalty we all pay for building production apps in something even a staff engineer is “junior level” with- often because that thing is only a couple of years old.
An interesting nomenclature/metaphor... bloated software as a "Big Ball of Mud"...<p>Related:<p><a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Technical_debt</a><p><a href="https://en.wikipedia.org/wiki/Code_smell" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Code_smell</a><p><a href="https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/" rel="nofollow noreferrer">https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...</a>
> According to you what were the contributing factors?<p>CTO too focussed on marketing, patting themselves on the back at offsites, and not paying attention the architecture, injudiciously delegating the responsibility by hiring the wrong type of senior Architect. One whose solution to everything is a paradigm/acronym/framework/buzzword/microservice and complexity reduction isn't in their DNA - they want to pad their resume instead.<p>CTO remains happy if the team do buzzword things he/she hears that Big Tech do<p>Focussing too much on tech and not the data/model is another one.