• (cs)

    Classes, packages/assemblies, applications, or services?

    (That sort of mess with classes is just cause to refactor. With packages, it's a mess that will take some very careful taming; time to check for version clashes. With applications… well, you're in a whole heap 'o trouble there. With services, especially if you're not considering individual deployments of them, it's time to consider doing something simpler like juggling with chainsaws or brain surgery.)

  • Max (unregistered) in reply to LieutenantFrost

    It's not the number of modules that is disturbing, but the number of dependencies. Why do they have to depend on each other so much? Interfaces containing unrelated methods, forcing to use something that wouldn't otherwise be used?

    Something isn't right IMO.

  • (cs) in reply to Xan
    LieutenantFrost:
    Amateurs. I can still see the light of day through that dependency graph. Behold our enterprise-ness and despair:

    http://img222.imageshack.us/img222/7504/tes0001.jpg

    (Warning...not for the faint of heart.)

    Does your company employ Outer gods and other lovecraftian abominations. Let me guess, Your senior architect is named Azathoth...

  • (cs) in reply to bebna
    bebna:
    What was the name of the depency tool?
    TRWTF is trying to get decent output for any real-world graph of any significant size out of Graphviz/dotty.

    (Note to #333393: the tool you found uses this library behind the scenes.)

  • (cs) in reply to Max
    Max:
    It's not the number of modules that is disturbing, but the number of dependencies. Why do they have to depend on each other so much? Interfaces containing unrelated methods, forcing to use something that wouldn't otherwise be used?

    Something isn't right IMO.

    It has to do with the fact that the people who started this system knew nothing about programming: one CTO/CIO, one machine systems guy, and a helpdesk guy. The first actual "programmer" wasn't brought in for about a year.

    galgorah:
    Does your company employ Outer gods and other lovecraftian abominations. Let me guess, Your senior architect is named Azathoth...
    We don't have a senior architect. [:(]
  • trwtf (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    Max:
    It's not the number of modules that is disturbing, but the number of dependencies. Why do they have to depend on each other so much? Interfaces containing unrelated methods, forcing to use something that wouldn't otherwise be used?

    Something isn't right IMO.

    It has to do with the fact that the people who started this system knew nothing about programming: one CTO/CIO, one machine systems guy, and a helpdesk guy. The first actual "programmer" wasn't brought in for about a year.

    galgorah:
    Does your company employ Outer gods and other lovecraftian abominations. Let me guess, Your senior architect is named Azathoth...
    We don't have a senior architect. [:(]

    I don't believe you. You don't get that screwed up without someone architecting away like billy-o. There's an architect in there somewhere, and now he's made himself a nest in all of that. You'll never get rid of him now - the only solution is to take off and nuke the place from orbit.

    It's the only way to be sure.

  • (cs) in reply to toshir0
    toshir0:
    Coyne:
    Spaghetti-code rules!

    (...and you-all thought it died with the GO TO!)

    When do you *believe* it died ?

    Well, I know it never did...but there are some people out there who think it died with Pascal.

    All that happened was that GO TO was traded in for even better methods of creating a heap of spaghetti: Exceptions, and now enterprisey software that has approximately 9 bazillion dependencies on two objects, "Generics" and "StoredProcedure".

    Translated to real life: They take away our knives, we go to guns; they take away the guns we go to nukes, etc., etc.

  • (cs) in reply to trwtf
    trwtf:
    I don't believe you. You don't get that screwed up without someone architecting away like billy-o. There's an architect in there somewhere, and now he's made himself a nest in all of that. You'll never get rid of him now - the only solution is to take off and nuke the place from orbit.

    It's the only way to be sure.

    Is there an "anti-architecture" anti-pattern? It's pretty much just two full-time devs and three part-time devs, each doing their own thing and hoping that it somehow comes together.

    And I'm already warming the engines up for takeoff on my orbital bombardment mission, by the by.

  • Anon (unregistered)

    I'm going to post this as Anon because: a) I'm the senior dev at my company and I should know better. b) Worst yet I implore my developers to reduce dependencies on a daily basis.

    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

  • Thijs (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    Amateurs. I can still see the light of day through that dependency graph. Behold our enterprise-ness and despair:

    http://img222.imageshack.us/img222/7504/tes0001.jpg

    (Warning...not for the faint of heart.)

    Damn I could confuse that for the architecture/routing map of Europe with the northern line of Africa..

  • rycamor (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    trwtf:
    I don't believe you. You don't get that screwed up without someone architecting away like billy-o. There's an architect in there somewhere, and now he's made himself a nest in all of that. You'll never get rid of him now - the only solution is to take off and nuke the place from orbit.

    It's the only way to be sure.

    Is there an "anti-architecture" anti-pattern? It's pretty much just two full-time devs and three part-time devs, each doing their own thing and hoping that it somehow comes together.

    And I'm already warming the engines up for takeoff on my orbital bombardment mission, by the by.

    Hey, I know..!! You could rewrite the application with a rules-processing engine, using rules expressed in a DSL done in Scala, with overlaying mini-DSLs done in Ruby for each section of the view! And then you could get rid of that annoying relational database back-end and use a key-value store running in Erlang. Time to think big!

  • (cs) in reply to trwtf
    trwtf:
    LieutenantFrost:
    galgorah:
    Does your company employ Outer gods and other lovecraftian abominations. Let me guess, Your senior architect is named Azathoth...
    We don't have a senior architect. [:(]

    I don't believe you. You don't get that screwed up without someone architecting away like billy-o. There's an architect in there somewhere, and now he's made himself a nest in all of that. You'll never get rid of him now - the only solution is to take off and nuke the place from orbit.

    It's the only way to be sure.

    I'll fix his mess for the low rate $400/hr as long as I am only referenced with the vague title of "The Cleaner". Course, I will require all the documentation pertaining to this "enterprise framework", in addition to several other "supplies".

  • (cs) in reply to LieutenantFrost

    It's a fish! Shooting fireworks out of its mouth! And, umm, an umbrella also sticking out of its mouth.

  • вà (unregistered)

    Something's fishy here. There's no way human beings can concentrate that much to produce such a web like that. The invasion has begun...

  • John Doe (unregistered) in reply to LieutenantFrost

    Looks like something a cat would LOVE to play with...

  • A Nonny Mouse (unregistered) in reply to TheCPUWizard
    all dependencies behind a factory should be "soft" (e.g. injected) except for the interfaces produced by the factory

    Injection? Where's the pattern for that?

    Face it, that is the way factories are used in the real world. i.e. in the world where many programmers have trouble with the for and while patterns, or the pattern where classes are capable of instantiating themselves.

    When I had to reuse an existing framework at work, I ended up removing all the patterns, especially the factories and singletons, in order to solve the everything-depends-on-everything problem.

  • (cs) in reply to LieutenantFrost

    Good evening, LieutenantFrost!

    All your Enterprise are belong to us!!!

  • The Web is the Root of All Info (unregistered) in reply to DaveK

    If the graph data can be exported, I'd recommend yEd: http://www.yworks.com/en/products_yed_applicationfeatures.html

    It specializes in laying out diagrams, so it could make a better looking/comprehensible graph.

  • (cs) in reply to Anon
    Anon:
    I'm going to post this as Anon because: a) I'm the senior dev at my company and I should know better. b) Worst yet I implore my developers to reduce dependencies on a daily basis.

    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

    I can think of two ways right off the bat.

    1. Shared source files (not assemblies).

    2. Make a base framework to build applications from.

  • (cs) in reply to Cad Delworth
    Cad Delworth:
    Good evening, LieutenantFrost!

    All your Enterprise are belong to us!!!

    beep boop

    I AM LEGION

  • Patrick S (unregistered) in reply to John Doe
    John Doe:
    Looks like something a cat would LOVE to play with...

    Are you kidding? That looks like something that would eat the cat! Especially the one in the featured comments.

  • Christopher Martin (unregistered)

    Any chance we could get a higher-res version of this image? I'd like to set it as my desktop background. It makes me feel better about my own life.

  • rycamor (unregistered) in reply to Anon
    Anon:
    I'm going to post this as Anon because: a) I'm the senior dev at my company and I should know better. b) Worst yet I implore my developers to reduce dependencies on a daily basis.

    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

    I wish I had a good answer. As an older person, I could probably say some snarky things about Agile, Design Patterns, frameworks and all the other fads and methodologies of the past decade or two that seem to have had the opposite effect of their stated intent. But I know there's more to it than that.

    There are many different kinds of programs and what seems to make sense in one sphere doesn't in another. For example, I find it amazing that a whole operating system or major open source application (Linux, FreeBSD, PostgreSQL, Apache) can live as a cohesive system given contributions from disparate teams and developers around the world, but a single application done by a team of six somehow requires daily meetings in order to have the slightest amount of cohesiveness to the project (at least, that's what some methodologists would have us believe).

    My personal axe to grind in all of this is the whole concept of ORM (Object-relational mapping). For data-driven business applications, the relational model offers the only truly logical way to reduce dependencies to their pure minimums while still enforcing requirements. Unfortunately, because of the notions of ORM, we need to completely replicate all of the logic expressed in the relational database into our classes and members. And given that classes are hierarchical (or at least network-based), rather than set-based, they cannot really reproduce relational without at least an additional axis of dependency. Of course, developers hate DBAs and DBAs hate developers and everybody hates those poncy database architects, and relational databases themselves are not really relational (IOW the relational-ness can be subverted easily), so we still have a big mess.

    In other words, we need to do better on the database/logic end, and then our application level can enjoy much lower dependency requirements. And by this I mean the opposite of the whole NoSQL craze. The SQL patterns that the NoSQL people object to are usually antipatterns anyway.

    Of course, this is all at the armchair-theorist level. I have not done any studies proving my conjectures, but I think there is something to it.

  • (cs)

    I think the graph looks like this, personally. Use your imagination a bit.

  • (cs) in reply to Christopher Martin
    Christopher Martin:
    Any chance we could get a higher-res version of this image? I'd like to set it as my desktop background. It makes me feel better about my own life.
    I uploaded a high-res version to imageshack earlier, but it seems that the pic was hijacked. Shoot me a PM and I'll e-mail it.
  • Anon (unregistered)

    Sort of looks like a hairnet the people behind the deli counter have to wear.

  • saluto (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    Christopher Martin:
    Any chance we could get a higher-res version of this image? I'd like to set it as my desktop background. It makes me feel better about my own life.
    I uploaded a high-res version to imageshack earlier, but it seems that the pic was hijacked. Shoot a PM and I'll e-mail it.
    FTFY
  • (cs)

    They needed a tool to produce this? It's no more than a single order of magnitude more complex than the one I once had to make by hand.

  • daqq (unregistered)

    Fools! Drawing the occult diagram to invoke Codethulu without proper protection!? We're doomed... DOOOOOOOMED!

  • SlyJeff (unregistered) in reply to Anon
    Anon:
    I'm going to post this as Anon because: a) I'm the senior dev at my company and I should know better. b) Worst yet I implore my developers to reduce dependencies on a daily basis.

    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

    Small classes with single responsibilities Dependency injection Program to interfaces TDD makes doing all of the above a lot easier (but is not the only way to get there)

  • (cs) in reply to Anon
    Anon:
    I'm going to post this as Anon because: a) I'm the senior dev at my company and I should know better. b) Worst yet I implore my developers to reduce dependencies on a daily basis.

    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

    One thing that comes to mind is not making your own "object" (and calling it "Generic") and not using one shared stored procedure accessor (named "StoredProcedure") for everything in the system.

    In the monster under consideration, on the face it appears that about 50% of the links lead to "StoredProcedure" on the right and 30% or so to "Generic" on the left.

    Considering "StoredProcedure" specifically, it appears they either have several thousand "object types" that require "StoredProcedure" as part of the implementation (imbedded rather than inherited) or else they are using "StoredProcedure" as an "RPC" mechanism to access multiple stored procedures (implying a non-O-O data retrieval model).

    Either way, the result would be (is?) non-O-O spaghetti.

  • (cs) in reply to Coyne
    Coyne:
    One thing that comes to mind is *not* making your own "object" (and calling it "Generic") and not using one shared stored procedure accessor (named "StoredProcedure") for everything in the system.

    In the monster under consideration, on the face it appears that about 50% of the links lead to "StoredProcedure" on the right and 30% or so to "Generic" on the left.

    Considering "StoredProcedure" specifically, it appears they either have several thousand "object types" that require "StoredProcedure" as part of the implementation (imbedded rather than inherited) or else they are using "StoredProcedure" as an "RPC" mechanism to access multiple stored procedures (implying a non-O-O data retrieval model).

    Either way, the result would be (is?) non-O-O spaghetti.

    You're not far off, and you do bring up an interesting point. Y'all have been WTF'ing at the dependency graph, but there isn't even any code listed. I'd have to listen for the sounds of a million heads popping if I were to do that.
  • Mike D. (unregistered) in reply to LieutenantFrost

    My God... it's full of bars.

  • Luke (unregistered)

    Object-orientation in a nutshell.

  • Eduardo (unregistered) in reply to LieutenantFrost

    What's that a map of? It's too low-res to tell.

  • David Wright (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    I uploaded a high-res version to imageshack earlier, but it seems that the pic was hijacked. ...

    It seems to have moved to http://img510.imageshack.us/f/tes0000.jpg/

    If you click on the image, you get the hi-res version - which if you save locally turns out to be a 6358 x 4706 image. 10 MPixels high enough res for you? And yes you CAN read the names on all the boxes.

  • David Wright (unregistered) in reply to David Wright

    ... 10 MPixels high enough res for you? Sorry, that should be 30 MPixels high enough res for you?

  • (cs)

    A few have posted seemingly serious inquiries into who to deal with a mess like this, or even better, avoid it in the first place.

    Anyone interested in serious discussion, can feel free to contact me directly. Just use your favoirte search engine on my handle to get my direct e-mail address...

  • Veldang (unregistered) in reply to LieutenantFrost
    LieutenantFrost:
    Amateurs. I can still see the light of day through that dependency graph. Behold our enterprise-ness and despair:

    http://img222.imageshack.us/img222/7504/tes0001.jpg

    (Warning...not for the faint of heart.)

    If your enterprise-ness blots out the sun then we shall dependency graph in the shade!

    ratis- This isn't ratis! THIS IS ENTERPRISE!

  • Timbo (unregistered)

    Looks like some of the biological models I work on: see http://reactome.net/

  • (cs)

    I can't get this magic eye thing to work. What's it supposed to be?

  • Cheong (unregistered)

    If you work on any Windows project, there's actually lots of dependency unseen. Just don't let them get into your radar and let you loose the image.

    Say your project has a StoredProcedure class that lots of other class dependent on, but if you're working on any database related on .NET, you'll find youself depend on any of the Sql*/Odbc*/Ole* etc. classes too.

    Now just pretend the class is framework provided and blackboxed and don't think about how thinks work inside... That the point of abstraction.

    Focus on the class you're working on. If you ignore the general utility classes and still see more than a dozen class it depends on, it's probably time for you to decide to move on.

  • SMK (unregistered) in reply to LieutenantFrost

    I thought you said it was an enterprise diagram. It looks like you sent us a diagram of a planet surrounded by (natural & artificial) satellites instead.

    CAPTCHA Test: appellatio

  • (cs) in reply to Anon
    Anon:
    The question is simple, how do you avoid the above situation without endlessly duplicating code in all of your assemblies?

    By late binding dependencies!

    That way the dependency mapping tool wont be able to detect these links, and the graph should look much cleaner! ;D

  • Poochy.EXE (unregistered) in reply to SQLDave
    SQLDave:
    I can't get this magic eye thing to work. What's it supposed to be?
    I think it's the hair trap in Colin Mochrie's shower drain.
  • Herby (unregistered)

    But wait there's more. This is a job for http://turbosnakedraincleaner.com/

    Somehow Akismet thinks that this is spam in a shortened form so I am including this sentence.

  • J (unregistered) in reply to LieutenantFrost

    It looks more like an abstract map of Europe to me...

  • My Name (unregistered) in reply to TheCPUWizard

    Oh. My. God.

    I can't believe it. Can I trust my eyes?

  • Phil (unregistered) in reply to Herby
    Herby:
    But wait there's more. This is a job for http://turbosnakedraincleaner.com/

    Somehow Akismet thinks that this is spam in a shortened form so I am including this sentence.

    turbo's naked rain cleaner?

  • My Name (unregistered) in reply to Phil
    Phil:
    Herby:
    But wait there's more. This is a job for http://turbosnakedraincleaner.com/

    Somehow Akismet thinks that this is spam in a shortened form so I am including this sentence.

    turbo's naked rain cleaner?

    Just like penis land on http://penisland.com.

Leave a comment on “The Enterprise Dependency”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article