• ray10k (unregistered)

    This is giving me a headache, just looking at it.

  • snoofle (unregistered)

    As long as none of those parameters are Booleans, they'll be OK.

  • bvs23bkv33 (unregistered) in reply to snoofle

    tri-booleans? like OK in addition to true and false?

  • bvs23bkv33 (unregistered)

    error: big ball yarn link leads to same place as enterprise dependency

  • Oliver Jones (google)

    Fractal software engineering takes its rightful place alongside fractal critical-path project planning in the WTF Hall of Fame! Long overdue.

  • (nodebb)

    I just want to know, what was used to create this image? I actually like how it lays things out, at least that part isn't a WTF.

  • (nodebb)

    Sad truth about large-scale systems: You can push the dependency graph up or down the layers but if you show the whole thing it's still going to look like this. Complexity sucks, but that's why they call it complexity.

    The real world is the über enemy of simplicity.

  • Brandon (unregistered)

    I call them spaghetti knots. They're all knotted up and if you try to untangle them, they fall apart.

  • Bill (unregistered)

    That looks a lot like the ClearCase version tree for some cellphone code I worked on about 10 years ago.

  • ichbinkeinroboter (unregistered) in reply to CoyneTheDup


  • (nodebb) in reply to bvs23bkv33

    like OK in addition to true and false?

    FILE_NOT_FOUND weeps to be forgotten…

  • Sandman (unregistered)

    The "Enterprise Dependency" image looks like a wad of hair that one just pulled from a brush

  • SteveO (unregistered)

    This isn't a WTF, this is art!

  • Brian Parker (google)

    You make it sound as though using stored procedures is the problem. Given how the application grew (and their decision to incorporate every customer's need into the code base), I don't see how putting the logic in a different layer would have made it less complex. I mean, the crazy graph might be at another layer instead, but I suspect it wouldn't have been magically cleaner.

    As ugly as platform-on-a-platform is, there's an unfortunate reason most ERP systems do it.

  • Apparently not H. L. Mencken (unregistered) in reply to CoyneTheDup

    For every complex problem there is an answer that is clear, simple, and wrong

  • RichP (unregistered) in reply to ray10k

    You get used to it after a while. I don't even see the code anymore, I see blond, redhead...

  • Sole Purpose of Visit (unregistered) in reply to Brian Parker

    If the only way to access the data is through stored procedures (with the option to create more 3,000 line 100 parameter monstrosities that "tackle" the same schema), then stored procedures are, indeed, the problem.

    You're right, of course. A better solution would be to have a "core" set of tables, a set of "customer-focused tables" for each individual customer, and a sane design for the stored procedures at each level. However, once you buy in to "all business logic goes into the database, and everything else is just a thin wrapper around a GUI," then this is what you get. And you can't refactor any of these stored procedures, because "business logic is the core of our business."

    I was deeply moved by the fractals, though. Somehow this emergent beauty almost makes the whole twenty years of blood, tears and sweat worthwhile.


  • Jaloopa (unregistered) in reply to Bill


    You poor, poor soul

  • Ruud (unregistered)

    Looks like a map from the Starwars (tm) universe.

  • Object delete. (unregistered) in reply to Brandon

    Like Borromean rings. Youtube has a number of great videos about them.

  • Sole Purpose of Visit (unregistered) in reply to Sole Purpose of Visit

    I thought about this a little harder. I really don't dislike stored procedures as such.

    I'm going to claim that the problem doesn't lie with monstrously large stored procedures and 100 parameters. I mean, obviously, it does. Those are the present manifestation of the problem.

    But the basic problem is, not so much the length of the stored procedures (which is probably a WTF, but y'know legacy) as in the number of parameters.

    I'll lay good odds that, out of those 100, roughly 85 to 90 are "hello, it's me!" booleans (or moral equivalent), and only ten to fifteen at most are relevant to any individual customer.

    Which means that the problem here is that, basically, the idiots writing the "ORM" (insert moral equivalent) cannot be bothered to coalesce the 85 to 90 "hello it's me" parameters to a single validation/lookup/whatever.

    Not saying that this thought makes it any better. But hey ... fractals! Goldfish! Man, I ... what was I about to say?"

  • Drone (unregistered)

    Is the Mandelbrot truly an emergent property of the complexity, or just really good visualization? Maybe even a UI update with fancy new technology? ;)

    Still, pretty tho.

  • Simon (unregistered) in reply to KattMan

    That's SQL Dependency Tracker by Red Gate. You can choose different layouts and it'll rearrange them all swoosh like.

  • Simon (unregistered) in reply to KattMan

    Google also "The Art of the Execution Plan"

  • (nodebb)

    Looks like a Gordian knot to me. Totally untangleable.

  • diagram fan (unregistered)

    I wonder: had the dependency diagrams actually helped anyone ever or do we only bring them in when we know that the situation is way beyond any help?

  • Brian Parker (google) in reply to Sole Purpose of Visit

    You make good points.

  • Dan (unregistered)

    You misspelled ubercomplexificatified.

  • David (unregistered) in reply to Drone

    My guess is that the visualization software takes everything that's connected to each other and pushes it into a big circle, so if you had one big person table and one big item table and one big store table, and the only place they were mingled was in a sale table relating one item from each, you'd have a shamrock. If everything is interconnected, it all goes in one huge circle, with a few things that are tangentially connected to one point in that circle becoming new circles on the side.

Leave a comment on “The Big Balls of…”

Log In or post as a guest

Replying to comment #:

« Return to Article