• ParkinT (unregistered)

    Paula did not write this It is NOT in VB It is NOT in XML It is NOT on a wooden table This post is FIRST If I squint, it reminds me a little of "Irish Girl"

    It is PERFECT!

  • TheRealGrimmie (unregistered)

    not FRIST darn

  • crammy (unregistered) in reply to TheRealGrimmie

    Ok, which one of those central classes is named "String"?

  • (cs)

    It's a map of Europe!

  • (cs)

    No, it's a map of the Falkland Islands, oddly enough.

  • dna (unregistered) in reply to frits
    frits:
    It's a map of Europe!

    seriously... how can i missed that... i can see my house from here...

  • (cs)

    "Number of classes" is a pretty blurry metric for measuring code maintainability IMO. For example, which would you rather have: 20 classes that are very limited in responsibility, or 1 behomoth that does the job of those 20? A lot of classes is not a problem if your dependency diagram is relatively flat. Now, if your graph looks like the Empire State Building or a buckyball, you may have a problem.

  • (cs) in reply to dna
    dna:
    frits:
    It's a map of Europe!

    seriously... how can i missed that... i can see my house from here...

    I can't, but I can see my office...
  • Sylver (unregistered)

    I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

    Repeat the mantra:

    I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will...

    Arrrgh! Again, again... must. not. give. hope.

    I must not fear. Fear is the....

    Hey, wait a minute, it's not so bad. I am not the one in charge of that mess. Oh, I love my life.

  • (cs)

    The pic initially reminded me of when the Death Star destroyed Alderaan. Maybe the bits at the bottom could be imperial cruisers parked nearby to watch the 'show'.

  • (cs)

    Why can't I click on it for a full-sized version?

  • Rosuav (unregistered) in reply to steenbergh
    steenbergh:
    Why can't I click on it for a full-sized version?

    Preservation of sanity.

  • (cs)

    Remember more enterprisey systems meaning more employment. Simple economics diktate that we must have complex system so that entire civilisaton will stay employed.

    Idle minds are workships for Shaitan. That is means that we must keep all minds ocupied and this diagram just does that.

    Who's for employment? Madarchod!!!

  • KevinHamburger (unregistered)

    Holy crap, there's a class for each symbol on the ASCII table there.

  • Mmmpf (unregistered)

    Looks like the results of a "I read on the internet that patterns are good, so I implemented them all" kind of reasoning.

    How do you like my Model-View-View-Presenter-Model-View-Controller enterprise bus factory concern-separated service oriented piece of overexpensive unworking junk? Yes you have to press "Retry" when windows fail to load or when your screen starts to cry tears of blood, and the texts are in cyrillic, but it's just a small bug in the asynchronous transvertical resource manager service.

    But see, when you turn the mouse wheel, it switches from WPF to Silverlight then Metro then WinForms then Telescript then back to WPF again. Nice isn't it?

  • Martijn (unregistered) in reply to frits
    frits:
    "Number of classes" is a pretty blurry metric for measuring code maintainability IMO. For example, which would you rather have: 20 classes that are very limited in responsibility, or 1 behomoth that does the job of those 20? A lot of classes is not a problem if your dependency diagram is relatively flat. Now, if your graph looks like the Empire State Building or a buckyball, you may have a problem.

    That's a good point. One of the nice things about Scala compared to Java is that in Scala it's trivial to create a ton of classes that do something trivial, at no extra maintainance overhead. Not requiring a file per class is an enormous help there.

    I doubt that's really the case here, though.

  • (cs)

    1700 classes aren't that many. I've worked on far larger systems that were mostly OK.

    But those three classes that seem to have at least a hundred dependencies each... those scare me.

  • (cs) in reply to Mmmpf
    Mmmpf:
    when you turn the mouse wheel, it switches from WPF to Silverlight then Metro then WinForms then Telescript then back to WPF again.
    You, sir, are ahead of your time. I salute you.
  • Gilles (unregistered)

    On the first sight, I thought I was looking at a map of some unknown country.

  • esteban (unregistered) in reply to frits

    Good points.

    Also makes you wonder about the "easy-to-support legacy system which had around 100 classes". While I agree on the dangers of over-architecting, 100 classes sounds like the other end of the spectrum. Easy-to-support doesn't necessarily translate to quality code.

    Executives don't typically fund wall-to-wall rewrites unless there's a real need. If may have been easy-to-support, but did it scale to the performance and availability needs? How much maintenance did it require? How easy was it to add new feature blocks?

  • A mad arab... (unregistered)

    Deep within the bowels of the system Codethulhu sleeps, waiting till the epoch time is right.

    Captcha: odio - The spanish version of the "Day-o" song

  • Paul (unregistered)

    If you stare at it's miserable heart long enough, you can faintly make out something which looks like "V...GER".

  • Kempeth (unregistered) in reply to Mmmpf
    Mmmpf:
    How do you like my Model-View-View-Presenter-Model-View-Controller enterprise bus factory concern-separated service oriented piece of overexpensive unworking junk?
    Yo Dawg! I heard you like MVC so I put and MVC in your MVC so you can control your view and model while you control your view and model.
  • Allan Schatsky (unregistered)

    This raises so many pressing questions, like what's with the tiny, logical section at the bottom, and when will this be made available in desktop size?

  • (cs)

    I imagine one of the code reviews went like this:

    Q: "Where did you get the IEnterpriseAuthenticationProvider?"

    A: "It fell of a IEnterpriseAuthenticationProviderFactory"

    Q: "Where did the IEnterpriseAuthenticationProviderFactory come from?"

    A: "It fell off of a IEnterpriseAuthenticationProviderFactoryManagementFactory"

  • (cs) in reply to Martijn
    Martijn:
    That's a good point. One of the nice things about Scala compared to Java is that in Scala it's trivial to create a ton of classes that do something trivial, at no extra maintainance overhead. Not requiring a file per class is an enormous help there.
    The rest of us have switched from Notepad to professional IDEs about 10 or 15 years ago. (If someone has programmed Java with an IDE more than 17 years ago, please stand up!)

    Creating a new Java class in a modern IDE is an absolute triviality and a matter of seconds (still no laughing matter, though ;-)

    And the Java requirement of a file per class is something you have invented.

    A file can contain as many private java classes as you like.

    Even the requirement of only one public class per file is not really enforced by the Java Language Specification:

    Java Language Specification:
    When packages are stored in a file system (§7.2.1), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:
    • The type is referred to by code in other compilation units of the package in which the type is declared.
    • The type is declared public (and therefore is potentially accessible from code in other packages).
  • (cs) in reply to steenbergh
    steenbergh:
    Why can't I click on it for a full-sized version?

    It's actually a fractal, so it looks the same at all levels of zoom.

  • (cs)
    ...so, management commissioned the Next Generation project.
    Good name for a project, management, well done. Projects need to have names so you can easily identify them in conversation, but the marketing spin just makes it so much sweeter. It's a lot easier to sell a fashionable name than it is to get real buy-in for the project itself.

    Seriously, Next Generation. Who's gonna question that?

  • (cs) in reply to RichP
    RichP:
    I imagine one of the code reviews went like this:

    Q: "Where did you get the IEnterpriseAuthenticationProvider?"

    A: "It fell of a IEnterpriseAuthenticationProviderFactory"

    Q: "Where did the IEnterpriseAuthenticationProviderFactory come from?"

    A: "It fell off of a IEnterpriseAuthenticationProviderFactoryManagementFactory"

    Factories inside factories?

    Factory-ception.

    Or, if you prefer:

    Hey dawg, I heard you like factories, so I put a factory in your factory so you can create objects while you create objects!

  • David (unregistered) in reply to esteban
    esteban:
    Good points.

    Also makes you wonder about the "easy-to-support legacy system which had around 100 classes". While I agree on the dangers of over-architecting, 100 classes sounds like the other end of the spectrum. Easy-to-support doesn't necessarily translate to quality code.

    Executives don't typically fund wall-to-wall rewrites unless there's a real need. If may have been easy-to-support, but did it scale to the performance and availability needs? How much maintenance did it require? How easy was it to add new feature blocks?

    It's possible the the legacy system had poor architecture but was decently coded in other respects. Someone who is capable of transforming 100 classes into 1700 probably suffers from at least a little hubris and that may have lead them to condemn the legacy code.

  • (cs) in reply to boog
    boog:
    ...so, management commissioned the Next Generation project.
    Good name for a project, management, well done. Projects need to have names so you can easily identify them in conversation, but the marketing spin just makes it so much sweeter. It's a lot easier to sell a fashionable name than it is to get real buy-in for the project itself.

    Seriously, Next Generation. Who's gonna question that?

    Fans of TOS, obviously.

  • Dazed (unregistered) in reply to frits
    frits:
    "Number of classes" is a pretty blurry metric for measuring code maintainability IMO.
    Yes, I'll grant you that.
    frits:
    For example, which would you rather have: 20 classes that are very limited in responsibility, or 1 behomoth that does the job of those 20?
    That's not so clear. I suspect I'd prefer half a dozen classes which each does a reasonable amount of work.

    The point is that complexity within a class and complexity of relationships between classes are both matters of concern. It seems to have become very fashionable to worry mostly about the first and hardly at all about the second. And that is every bit as bad as doing it vice versa.

  • Sheldon Cooper (unregistered)

    The company needs an architect to derive abstract models from the full picture. That will reduce complexity of the mapped problem to a reasonable level. There seem to be systematic naming conventions, suggesting the implementors were disciplined and rigorous. Design Patterns are a public domain, which aids comprehension and eases up maintenance.

    There should be apparent a set of independent isolated autonomous coherent units as separate jars (Java Archives) that are later imported and used by other code. I'd like the job of re-engineering the architecture for this project from what there is. It's the Divide & Conquer kind of a game, which is fun.

  • AnonymousCoward (unregistered) in reply to KevinHamburger

    You mean a class for every Unicode code point, surely?

    There's FAR too many classes to cover just the ASCII table :)

  • apoc9 (unregistered) in reply to frits
    frits:
    It's a map of Europe!
    No It's complete map of all EU departments.
  • (cs) in reply to apoc9

    I once worked in a project with such a graph... but it was a dependency graph! I didn't know there were so many Java libraries until that moment.

  • (cs)

    You know, for all the flak that "enterprisey" code gets, keep in mind it's a GOOD thing to have abstractions. True, you don't need the 

    HammerFactoryFactoryFactory
    type of things, but it's usually considered good practice to have a lot of interfaces that get passed around - in fact doing such things is the foundation of good design (see Robert C. Martin's SOLID principles).

    Having few classes is often worse than having many, because chances are those classes violate the SRP and do more than one thing. Granted, something like the illustration here is outright ridiculous and way too complicated, but it's not always a bad thing to have a lot of abstractions.

  • Mmmpf (unregistered) in reply to no laughing matter
    no laughing matter:
    The rest of us have switched from Notepad to professional IDEs about 10 or 15 years ago. (If someone has programmed Java with an IDE more than 17 years ago, please stand up!)

    I don't remember what I used before Visual Studio or Eclipse to write my code under Windows (probably UltraEdit), but I'm quite sure it wasn't Notepad. Actually now that I have absolutely no reason to use it, I started to like it, in a nostalgic way: it's there to remind me why I hated Windows so much (while still using it) back in the days: it does the smallest subset of things it is supposed to do, but in the worse possible way.

    Doesn't know how to cancel. Well yes it does, but just one time. Next time you cancel, it cancels the cancellation. Deeeep!

    Doesn't lock files when modifying it. You can open it, and it can get deleted. You still have it. It won't tell you anything if you save a deleted file: if you modified it, it will recreate it. If you didn't, it will just do nothing, keeping you in the warm illusion that your file still exists.

    Uses Ctrl+keystrokes. But if you're in a foreign language OS, it's all wrong. In Spanish for instance, Ctrl-G saves, Ctrl-A opens, Ctrl-B finds, Ctrl-R replaces, Ctrl-E selects all. Try to work with this. To its defense, some other Microsoft apps (Explorer, Office) use this retarded way of thinking localization.

    Doesn't know how to select a word by double-clicking it. Well yes it does, but the set of characters it considers as word separators is completely different for that of any other existing tool.

    Also, it has absolutely no functionality, but it has this entry in a menu to insert the current date and time. So it's a completely useless program, unless you want to rapidly insert the current date and time in a text file. In this case, it's the bomb.

  • Geir (unregistered)

    I think they have misunderstood the term "cloud computing". It looks like one, but...

  • iToad (unregistered)

    Good luck printing that out. I don't think it would be legible as an E size engineering drawing.

  • I am Zunesis (unregistered)

    This looks like my latest outbreak of HPV.

  • (cs) in reply to frits
    frits:
    It's a map of Europe!
    Not a map, just an artistic portrayal; it's abstract.
  • (cs) in reply to pjt33
    pjt33:
    boog:
    ...so, management commissioned the Next Generation project.
    Good name for a project, management, well done. Projects need to have names so you can easily identify them in conversation, but the marketing spin just makes it so much sweeter. It's a lot easier to sell a fashionable name than it is to get real buy-in for the project itself.

    Seriously, Next Generation. Who's gonna question that?

    Fans of TOS, obviously.
    It all depends on which project the stakeholders find to be more enterprisey.

  • Johann (unregistered)

    If you look closely, you can see the Higgs-Boson.

  • Russ (unregistered)

    Enterprise Shrubbery

  • Mmmpf (unregistered) in reply to boog
    boog:
    frits:
    It's a map of Europe!
    Not a map, just an artistic portrayal; it's abstract.

    Europe is abstract too. It's a fading concept.

  • esteban (unregistered) in reply to David
    David:
    esteban:
    Good points.

    Also makes you wonder about the "easy-to-support legacy system which had around 100 classes". While I agree on the dangers of over-architecting, 100 classes sounds like the other end of the spectrum. Easy-to-support doesn't necessarily translate to quality code.

    Executives don't typically fund wall-to-wall rewrites unless there's a real need. If may have been easy-to-support, but did it scale to the performance and availability needs? How much maintenance did it require? How easy was it to add new feature blocks?

    It's possible the the legacy system had poor architecture but was decently coded in other respects. Someone who is capable of transforming 100 classes into 1700 probably suffers from at least a little hubris and that may have lead them to condemn the legacy code.

    Hubris, check.

    Don't get me wrong, I agree with the general thread that the thing looks like an over-engineered beast. Doesn't seem to be any agile 'build what you know you need' evident. My point is that large systems do this kind of refactoring, and get funding, for a reason -- not just because someone thinks its cool.

  • (cs) in reply to Mmmpf
    Mmmpf:
    boog:
    frits:
    It's a map of Europe!
    Not a map, just an artistic portrayal; it's abstract.

    Europe is abstract too. It's a fading concept.

    Notice how Italy and Greece are missing.

  • Mmmpf (unregistered) in reply to frits
    frits:
    Mmmpf:
    boog:
    frits:
    It's a map of Europe!
    Not a map, just an artistic portrayal; it's abstract.

    Europe is abstract too. It's a fading concept.

    Notice how Italy and Greece are missing.

    Wait a bit and all that will be left will be the fake smile of phony politics.

  • (cs) in reply to esteban
    esteban:
    Executives don't typically fund wall-to-wall rewrites unless there's a real need. If may have been easy-to-support, but did it scale to the performance and availability needs? How much maintenance did it require? How easy was it to add new feature blocks?
    Not so sure that I agree. I've seen many projects where executives are sold on some Shiny New Technology, funding wall-to-wall rewrites of existing, proven systems when there was no real need. Being on the latest bandwagon is not a real need.

    You ask how well the old system scaled to performance and availability needs, maintenance, ease of adding new features, blah blah, but these things are rarely, if ever, measured correctly and impartially when considering a Shiny New Technology. The novelty of something new is too much to resist; people who buy into the hype (executives and programmers alike) will convince themselves they are being fair, when they're unwittingly misrepresenting the actual costs of the current system, and vastly underestimating the total costs of the new system.

    I'm not saying you're wrong, just that it happens more often than you'd think.

Leave a comment on “Enterprise Dependency: The Next Generation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article