6 ms·

Dorodango is one of my favorite metaphors for operationalizing software. Start with any codebase, no matter how naively or ineptly implemented. Grind administra

Dorodango is one of my favorite metaphors for operationalizing software. Start with any codebase, no matter how naively or ineptly implemented. Grind administrators against it in production for years and inevitably it will become a smooth, shiny and stable component. Often we talk about the power of inertia in keeping around old codebases with terrible histories. We talk about how illogical it is that we don't throw things out and start anew. There's a hidden value in a known quantity which has had blemishes polished off. With a nod to mythbusters, even a turd can shine [1] given sufficient effort. We have all dealt with many turds in the course of our careers. It is of course ideal to polish something more valuable than a turd. Architecture can still be rotten on the inside and necessitate replacement despite having a well polished exterior process. But new systems will always be unpolished no matter how well design. In the end there is no substitute for the smoothing process of constant handling. [1] https://go.discovery.com/tv-shows/mythbusters/videos/polishing-a-turd-minimyth https://go.discovery.com/tv-shows/mythbusters/videos/polishi...

asddubs 5y ago
and here i was taught to avoid a ball of mud architecture
- throwaway09223 5y ago
  Yes whenever possible, hah. "I am prepared for the worst, but hope for the best." - Disraeli
annoyingnoob 5y ago
> Grind administrators against it in production for years Screw you, I quit!
- praptak 5y ago
  There's a Zen saying: “Like the pebbles in a bag, the monks polish one another.” We could modify this to handle sysadmins too.
  - annoyingnoob 5y ago
    The only lesson in suffering under your job duties as a sysadmin is "don't do that". There is little glory in polishing production poo, even if you can. You should be showing a better way, not reinforcing bad decisions because you are a superhero.
    - throwaway09223 5y ago
      I would say there's little glory in quietly polishing poo, in smoothing over problems without visibility. I agree it's not good to suffer in silence. However, the political reality in any large company means shit will be shipped on a regular basis. This isn't unique to the dev/sysadmin roles. This happens in every area of business. There's enormous glory to be had in visibly polishing turds - in mitigating well known, well communicated problems. Prevention is very important, yes, but it is not a panacea.
bitwize 5y ago
> Start with any codebase, no matter how naively or ineptly implemented. Grind administrators against it in production for years and inevitably it will become a smooth, shiny and stable component. Kind of the culmination of the "Big Ball of Mud" architecture, innit.
etaioinshrdlu 5y ago
My metaphor for how software is actually created is Katamari Damacy (https://katamari.fandom.com/wiki/Katamari_Damacy https://katamari.fandom.com/wiki/Katamari_Damacy): a giant ball of random objects that keep getting bigger, and more and more random crap just sticks to the ball. That's all there really is to it.
- zimpenfish 5y ago
  > a giant ball of random objects that keep getting bigger, and more and more random crap just sticks to the ball Plus every now and then there's a reset where it all goes back to a tiny cohesive start before the chaos begins again.
- medstrom 5y ago
  The metaphor can be refined; there are balls that grow well and balls that fall apart. You reminded me of the old quote from R1RS 1978 (https://dspace.mit.edu/handle/1721.1/6283 https://dspace.mit.edu/handle/1721.1/6283) page 29: > APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!
hawski 5y ago
Rob Landlay made a similar observation, but I'm the end named the project Toybox instead of Dorodango.
bunsenhoneydew 5y ago
One that I’ve used a few times is “you can’t polish a turd… but you can roll it in glitter”
- gameswithgo 5y ago
  mythbusters polished a turd. :)
cassonmars 5y ago
Retaining and maintaining a legacy can be the right path when the external processes that interface with them are heavily laden with bureaucracies or qualifications that are slow or expensive to change. Accounting is a great example, as are power plants and telecoms. But it’s important to recognize in industries with rapidly evolving standards, throwing things out can be the answer. This came back to famously bite Joel Spolsky in his defense of legacy code [1] where he argued against Netscape’s complete rewrite, which we now know today as Mozilla. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Rapzid 5y ago
My favorite analogy is log structured merge trees.. Which seems to be a rather fitting for Dorodango.
zengargoyle 5y ago
No joke, back in like 1985 or so when I was in high school I found a book in the public library that was a tour of various computer languages. Like all of them. PL/I, SNOBOL, Lisp, Smalltalk, the old ones from ancient times. Each had a sample program and a few pages discussing the features of the language. The description for Forth had 'ball of mud' in it. That bottom-up design where you start with a tiny core and keep adding little bits and smoothing them out then adding more over and over. I always thought it was more like a snowball like in making a snowman sort of accumulation. But now... that final step when you have that last written that you give the command and the system removes all the bits that never get referenced from your application, squishes it down, polishes it up and spits out an executable. Forth is very dorodango.

asddubs 5y ago

and here i was taught to avoid a ball of mud architecture

throwaway09223 5y ago
Yes whenever possible, hah. "I am prepared for the worst, but hope for the best." - Disraeli

annoyingnoob 5y ago

> Grind administrators against it in production for years Screw you, I quit!

praptak 5y ago
There's a Zen saying: “Like the pebbles in a bag, the monks polish one another.” We could modify this to handle sysadmins too.
- annoyingnoob 5y ago
  The only lesson in suffering under your job duties as a sysadmin is "don't do that". There is little glory in polishing production poo, even if you can. You should be showing a better way, not reinforcing bad decisions because you are a superhero.
  - throwaway09223 5y ago
    I would say there's little glory in quietly polishing poo, in smoothing over problems without visibility. I agree it's not good to suffer in silence. However, the political reality in any large company means shit will be shipped on a regular basis. This isn't unique to the dev/sysadmin roles. This happens in every area of business. There's enormous glory to be had in visibly polishing turds - in mitigating well known, well communicated problems. Prevention is very important, yes, but it is not a panacea.

bitwize 5y ago

> Start with any codebase, no matter how naively or ineptly implemented. Grind administrators against it in production for years and inevitably it will become a smooth, shiny and stable component. Kind of the culmination of the "Big Ball of Mud" architecture, innit.

etaioinshrdlu 5y ago

My metaphor for how software is actually created is Katamari Damacy (https://katamari.fandom.com/wiki/Katamari_Damacy https://katamari.fandom.com/wiki/Katamari_Damacy): a giant ball of random objects that keep getting bigger, and more and more random crap just sticks to the ball. That's all there really is to it.

zimpenfish 5y ago
> a giant ball of random objects that keep getting bigger, and more and more random crap just sticks to the ball Plus every now and then there's a reset where it all goes back to a tiny cohesive start before the chaos begins again.
medstrom 5y ago
The metaphor can be refined; there are balls that grow well and balls that fall apart. You reminded me of the old quote from R1RS 1978 (https://dspace.mit.edu/handle/1721.1/6283 https://dspace.mit.edu/handle/1721.1/6283) page 29: > APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!

hawski 5y ago

Rob Landlay made a similar observation, but I'm the end named the project Toybox instead of Dorodango.

bunsenhoneydew 5y ago

One that I’ve used a few times is “you can’t polish a turd… but you can roll it in glitter”

gameswithgo 5y ago
mythbusters polished a turd. :)

cassonmars 5y ago

Retaining and maintaining a legacy can be the right path when the external processes that interface with them are heavily laden with bureaucracies or qualifications that are slow or expensive to change. Accounting is a great example, as are power plants and telecoms. But it’s important to recognize in industries with rapidly evolving standards, throwing things out can be the answer. This came back to famously bite Joel Spolsky in his defense of legacy code [1] where he argued against Netscape’s complete rewrite, which we now know today as Mozilla. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Rapzid 5y ago

My favorite analogy is log structured merge trees.. Which seems to be a rather fitting for Dorodango.

zengargoyle 5y ago

No joke, back in like 1985 or so when I was in high school I found a book in the public library that was a tour of various computer languages. Like all of them. PL/I, SNOBOL, Lisp, Smalltalk, the old ones from ancient times. Each had a sample program and a few pages discussing the features of the language. The description for Forth had 'ball of mud' in it. That bottom-up design where you start with a tiny core and keep adding little bits and smoothing them out then adding more over and over. I always thought it was more like a snowball like in making a snowman sort of accumulation. But now... that final step when you have that last written that you give the command and the system removes all the bits that never get referenced from your application, squishes it down, polishes it up and spits out an executable. Forth is very dorodango.