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

    It's a 1-to-1 scale map.

    I recognize the arrangement of blades of grass near a particular bench in a park in a small town outside Geneva.

  • SomeCoder (unregistered)

    Sounds like how we do business where I work. Rip out the easy to maintain but old (and sometimes hard to add new features to) system and replace it with something that is much slower, impossible to maintain, has a dependency graph like this one, and nobody except the original architect has any idea how to add new features to it. Perfect!

  • Tom (unregistered)

    It's the Angelina Jolie of dependency diagrams: oddly beautiful, but kinda crazy-scary, and I'm sure glad I'm not the one supporting it.

    And it's even got little orphans running along the bottom.

  • Could I Bother You to Recharge My Zune? (unregistered) in reply to I am Zunesis
    I am Zunesis:
    This looks like my latest outbreak of HPV.
    No you are not. ...but thanks for minding the store for me.
  • (cs) 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.
    Is "Seeing all Java developers get shot" an option?

    Because in my experience, Java developers have a tendency to generate a lot of glue on glue code. IntegerFactoryImplementationFactoryGeneratorImplementationInterface.

  • (cs) in reply to Tom
    Tom:
    It's the Angelina Jolie of dependency diagrams: oddly beautiful, but kinda crazy-scary, and I'm sure glad I'm not the one supporting it.

    And it's even got little orphans running along the bottom in Africa.

    FTFY

  • esteban (unregistered) in reply to boog
    boog:
    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.

    Agreed, bright shiny objects can distract, and yes, there are companies that have more money than sense. But even in those cases, I doubt you'd find that selecting New Technology X was the only driver for moving down a particular path.

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

    Preservation of sanity.

    Bigger than the dimension we live in.

  • (cs) in reply to esteban
    esteban:
    Agreed, bright shiny objects can distract, and yes, there are companies that have more money than sense. But even in those cases, I doubt you'd find that selecting New Technology X was the *only* driver for moving down a particular path.
    True, but my point was that many times the *other* drivers are still influenced by the one. For example: it may actually be cheaper (development and support costs) to correct the deficiencies of Old Technology Y than to replace/rewrite with New Technology X (which may have a host of unknown deficiencies, possibly exceeding those of Y in quantity and cost). But we may never know because those who've already committed themselves to New Technology X are likely to misrepresent (even unintentionally).
  • (cs) in reply to esteban
    esteban:
    boog:
    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.

    Agreed, bright shiny objects can distract, and yes, there are companies that have more money than sense. But even in those cases, I doubt you'd find that selecting New Technology X was the only driver for moving down a particular path.

    He's not saying that. He said that people will misrepresent the facts about the current system (exaggerate maintenance costs, etc.) and outright lie about "gains" in the proposed system, in order to get the rewrite approved.

  • (cs) in reply to Dazed
    Dazed:
    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.

    +1. Too many people out there using "design patterns" and "best practices" as excuses not to think instead of tools that can be useful in the appropriate circumstances.
  • Captain James T. Kirk (unregistered) in reply to boog
    boog:
    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 starship the stakeholders find to be more Enterprise-y.

    FTFY

  • Jay (unregistered) in reply to Severity One
    Severity One:
    No, it's a map of the Falkland Islands, oddly enough.

    Wow, that is EXACTLY what I thought when I first saw it. I mean, not just "It looks like a map", but "It looks like a map of the Falkland Islands."

    (For the Argentine readers, I mean the Isles Malvinas.)

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

    Preservation of sanity.

    Maybe he wants to use it as a model for his own next project.

  • (cs)

    That's really beautiful. Looks like an artist's impression of trees in the snow, as seen through a light winter mist.

  • (cs) in reply to brazzy
    brazzy:
    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.

    If you're looking at any sort of a decent application development framework, reuse of existing code will surely make it so that some classes or methods refer to dozens of other basic classes. There's nothing wrong with it. Even a trivial Hello World application done in, say, Qt framework, will pull in on the order of a hundred classes indirectly.

    The graph, as shown in the article, does not allow anyone to truly judge the quality of the code. You cannot judge anything because the classes lack the hierarchical context. Usually in a framework there are layers of classes: at the bottom are basic data structures (say QVector, QList, QString), higher up are various simple primitives that may use those (say graphic primitives, MVC model elements, etc), further on you have things that provide more functionality (widgets, OS interfaces, ...). Higher up you'll have application-specific stuff, and that has a hierarchy of its own that may parallel some of the framework's own hierarchy.

    With an autogenerated diagram, where generation was done in the most silly way possible (like in the fine article), you don't know what's where in terms of hierarchy. Thus you cannot judge anything. If you get Qt's class hierarchy into a similarly poorly done diagram, it will look no better, even if it's a fairly well designed framework.

  • Jay (unregistered) 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?

    I think there's a law that every new project proposal must include the words "next generation", "paradigm", "utilize", and "enterprise". Probably several other magic words I'm forgetting.

  • Marnen Laibow-Koser (unregistered) in reply to Kuba

    Exactly. There is somehow an implicit assumption being made here that more classes = bad. While one shouldn't overdesign, sometimes the clearest, best-factored design for a given system contains more classes, not fewer. Otherwise we'd all be writing procedural code shoved into one gigantic class...

  • (cs) in reply to esteban
    esteban:
    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.
    They get funding because people who decide about allocation of funds probably couldn't code themselves out of a paper bag. You can't make decisions about funding coding if you have no clue about it, and likely a layer or two of people under you has little clue as well (otherwise they would be 10 layers below, not one or two).
  • (cs) in reply to Mmmpf
    Mmmpf:
    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.

    Before eclipse we used TextPad. Now, when not using eclipse or whatever tool is appropriate for whatever other stuff I happen to be doing, I use Notepad++. I recommend it.

    Was pissing around the other day on a remote server on which I was debugging a large app supplied by a large company. Needed to view a its log file. Only file view tools were Notepad and WordPad. Couldn't view the file while the app was running. WTF!?!? Installed Notepad++ and everything honky dorky.

    So WTF haven't MicroShit sorted out their fucking file viewers in the last 25 fucking years?

  • (cs) in reply to Captain James T. Kirk
    Captain James T. Kirk:
    boog:
    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 starship the stakeholders find to be more Enterprise-y.

    FTFY

    People say that jokes are ruined when you explain them. Thank you for proving all of them wrong.

  • Uncle Al (unregistered) in reply to Matt Westwood
    Matt Westwood:
    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.
    And this is of course retarded because the letters chosen for ctrl-keystrokes should only by coincidence have any relation to the underlying command names in the local language, yes? (Though I'll admit surprise that "select all" isn't ctrl-T in a Spanish system...) For your next trick, are you going to explain how retarded it is for an application to make you type words from right to left when localized for Hebrew or Arabic?
  • (cs) in reply to Jay
    Jay:
    I think there's a law that every new project proposal must include the words "next generation", "paradigm", "utilize", and "enterprise". Probably several other magic words I'm forgetting.
    "Big picture". Also, "synergy", and its handful of variations.

    Oh, and lots of acronyms.

  • (cs) in reply to Jay
    Jay:
    I think there's a law that every new project proposal must include the words "next generation", "paradigm", "utilize", and "enterprise". Probably several other magic words I'm forgetting.
    * "Service-Oriented Architecture" * "X-As-A-Service" (Toilet-As-A-Service?) * "Cloud Computing" / alternatively: "in the Cloud" * "X-Driven-Y". Main variants: ** Model-Driven-Y (Architecture/Design/Development) ** Domain-Driven-Y ** Test-Driven-Y

    Paradigm-Shifting-Next-Generation-Zunesis-Driven-Porn-Browsing-As-A-Service-Oriented-Architecture-In-The-Enterprise-Cloud!

  • (cs) in reply to no laughing matter
    no laughing matter:
    Jay:
    I think there's a law that every new project proposal must include the words "next generation", "paradigm", "utilize", and "enterprise". Probably several other magic words I'm forgetting.
    * "Service-Oriented Architecture" * "X-As-A-Service" (Toilet-As-A-Service?) * "Cloud Computing" / alternatively: "in the Cloud" * "X-Driven-Y". Main variants: ** Model-Driven-Y (Architecture/Design/Development) ** Domain-Driven-Y ** Test-Driven-Y

    Paradigm-Shifting-Next-Generation-Zunesis-Driven-Porn-Browsing-As-A-Service-Oriented-Architecture-In-The-Enterprise-Cloud!

    The difference between your list and Jay's is most of those things are actual concrete technologies that people actually use.

    Or are you using trolling-as-a-service?

  • (cs) in reply to frits
    frits:
    no laughing matter:
    Jay:
    I think there's a law that every new project proposal must include the words "next generation", "paradigm", "utilize", and "enterprise". Probably several other magic words I'm forgetting.
    * "Service-Oriented Architecture" * "X-As-A-Service" (Toilet-As-A-Service?) * "Cloud Computing" / alternatively: "in the Cloud" * "X-Driven-Y". Main variants: ** Model-Driven-Y (Architecture/Design/Development) ** Domain-Driven-Y ** Test-Driven-Y

    Paradigm-Shifting-Next-Generation-Zunesis-Driven-Porn-Browsing-As-A-Service-Oriented-Architecture-In-The-Enterprise-Cloud!

    The difference between your list and Jay's is most of those things are actual concrete technologies that people actually use.

    Or are you using trolling-as-a-service?

    Troll-Driven-Commentary

  • Andy (unregistered)

    Just great! But does anybody know what tool was used to draw this picture? I'd be happy to try it on one of our projects...

  • esteban (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    esteban:
    boog:
    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.

    Agreed, bright shiny objects can distract, and yes, there are companies that have more money than sense. But even in those cases, I doubt you'd find that selecting New Technology X was the only driver for moving down a particular path.

    He's not saying that. He said that people will misrepresent the facts about the current system (exaggerate maintenance costs, etc.) and outright lie about "gains" in the proposed system, in order to get the rewrite approved.
    We're getting pretty far afield here. Just because an app gets rewritten, doesn't mean the bogeyman is out there. People make technology choices for lots of reasons, good and bad (I like IBM, or I own stock in Microsoft, or the sales rep I'm hitting on works at X, or my legacy app is hard to maintain and needs a full refresh). Whether it gets rewritten well or not is the question. If the legacy app in this case was pristine nirvana, then by all means, the rewrite was pointless. Personally, I've never seen a green-field rewrite that didn't, at it's core, have a fundamental set of problems that needed to be solved and accountability for ROI, in addition to the political/religious technology preferences that went with it.

  • r66 (unregistered) in reply to boog

    I am sure, the generation after "the Next Generation" will seriously question this name choice when they start their next-generation-rewrite.

  • (cs) in reply to esteban
    esteban:
    Just because an app gets rewritten, doesn't mean the bogeyman is out there.
    Oh, I assure you I'm real.
    esteban:
    People make technology choices for lots of reasons, good and bad... Whether it gets rewritten well or not is the question.
    It's certainly important, but the question here is whether a rewrite is necessary. Even a well-written rewrite can be unnecessary.
    esteban:
    If the legacy app in this case was pristine nirvana, then by all means, the rewrite was pointless.
    Or in another case: What if the legacy app is stable, but maybe requires a gentle nudge from a developer every few months, needs a small module or two added or implemented, and has a handful of minor data transformation bugs? I would say a rewrite is pointless there as well; those issues could be resolved in a matter of weeks, maybe days. Some people would throw it out in favor of a rewrite, hoping to avoid all those documented flaws by design (and disregarding any undocumented flaws that come up in the rewrite).
    esteban:
    Personally, I've never seen a green-field rewrite that didn't, at it's core, have a fundamental set of problems that needed to be solved and accountability for ROI, in addition to the political/religious technology preferences that went with it.
    Personally, I've never seen a legacy app that was perfect to begin with. Any application that has support costs could be said to "have a fundamental set of problems" by anybody who wants to do the work of a rewrite (or take credit for it).
  • JayC (unregistered) in reply to Kuba
    Kuba:
    brazzy:
    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.

    If you're looking at any sort of a decent application development framework, reuse of existing code will surely make it so that some classes or methods refer to dozens of other basic classes. There's nothing wrong with it. Even a trivial Hello World application done in, say, Qt framework, will pull in on the order of a hundred classes indirectly.

    The graph, as shown in the article, does not allow anyone to truly judge the quality of the code. You cannot judge anything because the classes lack the hierarchical context. Usually in a framework there are layers of classes: at the bottom are basic data structures (say QVector, QList, QString), higher up are various simple primitives that may use those (say graphic primitives, MVC model elements, etc), further on you have things that provide more functionality (widgets, OS interfaces, ...). Higher up you'll have application-specific stuff, and that has a hierarchy of its own that may parallel some of the framework's own hierarchy.

    With an autogenerated diagram, where generation was done in the most silly way possible (like in the fine article), you don't know what's where in terms of hierarchy. Thus you cannot judge anything. If you get Qt's class hierarchy into a similarly poorly done diagram, it will look no better, even if it's a fairly well designed framework.

    +1 agreed. If you define an interface or abstract class, and 100 things depend upon that interface/abstract class, with this dependency software, it looks like you'd get a big fuzzy ball, like (what looks like a few) of the classes shown.

    THE Real WTF is the lack of clarity dependency diagram.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    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
    Stop Stop Stop! HammerFactoryFactoryFactory time!
  • esteban (unregistered) in reply to boog
    boog:
    esteban:
    Just because an app gets rewritten, doesn't mean the bogeyman is out there.
    Oh, I assure you I'm real.
    esteban:
    People make technology choices for lots of reasons, good and bad... Whether it gets rewritten well or not is the question.
    It's certainly important, but the question here is whether a rewrite is necessary. Even a well-written rewrite can be unnecessary.
    esteban:
    If the legacy app in this case was pristine nirvana, then by all means, the rewrite was pointless.
    Or in another case: What if the legacy app is stable, but maybe requires a gentle nudge from a developer every few months, needs a small module or two added or implemented, and has a handful of minor data transformation bugs? I would say a rewrite is pointless there as well; those issues could be resolved in a matter of weeks, maybe days. Some people would throw it out in favor of a rewrite, hoping to avoid all those documented flaws by design (and disregarding any undocumented flaws that come up in the rewrite).
    esteban:
    Personally, I've never seen a green-field rewrite that didn't, at it's core, have a fundamental set of problems that needed to be solved and accountability for ROI, in addition to the political/religious technology preferences that went with it.
    Personally, I've never seen a legacy app that was perfect to begin with. Any application that has support costs could be said to "have a fundamental set of problems" by anybody who wants to do the work of a rewrite (or take credit for it).

    Heh... doesn't mean he isn't out there either.

    Agreed, but tacking back to my original points, the decision to rewrite isn't necessarily a bad thing, if the app is insufficiently healthy. That measuring stick is different for everyone, but if I heard an app was being gutted, (depending on context) I wouldn't necessarily assume mendacity straight off. Sometimes the rationale can be even more mundane -- we need to spend our budget.

    Granted, a bad rewrite can be worse than the devil you know, but then governance, especially over the two-year time frame in this example, is hard.

  • picard (unregistered)

    so, the number of classes [nc's, or NCC] is over 1700.

    like 1701?

    enterprizy

  • (cs) in reply to Uncle Al
    Uncle Al:
    Matt Westwood:
    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.
    And this is of course retarded because the letters chosen for ctrl-keystrokes should only by coincidence have any relation to the underlying command names in the local language, yes? (Though I'll admit surprise that "select all" isn't ctrl-T in a Spanish system...) For your next trick, are you going to explain how retarded it is for an application to make you type words from right to left when localized for Hebrew or Arabic?

    That wasn't my quote, bub, but let it go ...

  • (cs) in reply to esteban
    esteban:
    Agreed, but tacking back to my original points, the decision to rewrite isn't necessarily a bad thing, if the app is insufficiently healthy.
    Agreed.
    esteban:
    That measuring stick is different for everyone, but if I heard an app was being gutted, (depending on context) I wouldn't necessarily assume mendacity straight off.
    Which I think is a valid point - we can be weary of rewrites, but we shouldn't assume outright that people are deliberately lying to push a rewrite.

    That said, I'm going to take the submitter's description of the legacy software as "easy-to-support" to be my evidence that the rewrite was probably unnecessary, regardless of motivation. There's no way for me to know for sure; the submitter's word is the only evidence I have right now.

  • coyo (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    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.

    There is a correct balance between deep and wide. A programmer brain should be able to take in a unit a little less than a page long.
    I have seen 10,000 line long functions, which is way beyond too much.
    I've also seen messes of things so abstracted the code is just a mess of message passing single or double line subs.
    Numerous small classes are not better when, in order to understand the whole, you have to hunt down over a dozen to see what is happening. They are a royal pain for debugging, when you have to put print statements (or breakpoints if you like debuggers) across lots of classes to catch errors.
  • Bob (unregistered) in reply to Mmmpf
    Mmmpf:
    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.
    Please attempt some sensitivity. I had a son who was retarded, and let me assure you: it is no matter to be taken casually.
  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Before eclipse we used TextPad. Now, when not using eclipse or whatever tool is appropriate for whatever other stuff I happen to be doing, I use Notepad++. I recommend it.

    Was pissing around the other day on a remote server on which I was debugging a large app supplied by a large company. Needed to view a its log file. Only file view tools were Notepad and WordPad. Couldn't view the file while the app was running. WTF!?!? Installed Notepad++ and everything honky dorky.

    So WTF haven't MicroShit sorted out their fucking file viewers in the last 25 fucking years?

    Pising on remote servers will cautrize your pising tool, bro!

  • (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.
    Nonsense, it's been instantiated at least once.
  • (cs) in reply to boog
    boog:
    esteban:
    Agreed, but tacking back to my original points, the decision to rewrite isn't necessarily a bad thing, if the app is insufficiently healthy.
    Agreed.
    esteban:
    That measuring stick is different for everyone, but if I heard an app was being gutted, (depending on context) I wouldn't necessarily assume mendacity straight off.
    Which I think is a valid point - we can be weary of rewrites, but we shouldn't assume outright that people are deliberately lying to push a rewrite.

    That said, I'm going to take the submitter's description of the legacy software as "easy-to-support" to be my evidence that the rewrite was probably unnecessary, regardless of motivation. There's no way for me to know for sure; the submitter's word is the only evidence I have right now.

    If you have an application written in FORTRAN that functions smooth as you like, easy to use, etc. etc. whose only downsides are: a) The hardware it runs on is obsolete and no longer supported, and there is no appropriate replacement, and b) despite needing minimal ongoing maintenance, you can't find any staff either willing or able to perform this task, then reluctantly you find you have to upgrade.

    And let me assure you, that's no laughing matter.

  • (cs) in reply to coyo
    coyo:
    ObiWayneKenobi:
    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.

    There is a correct balance between deep and wide. A programmer brain should be able to take in a unit a little less than a page long.
    I have seen 10,000 line long functions, which is way beyond too much.
    I've also seen messes of things so abstracted the code is just a mess of message passing single or double line subs.
    Numerous small classes are not better when, in order to understand the whole, you have to hunt down over a dozen to see what is happening. They are a royal pain for debugging, when you have to put print statements (or breakpoints if you like debuggers) across lots of classes to catch errors.

    Given the choice I prefer the former to the latter, because then at least you have a nice meaty refactoring job on your hands which will keep you nice and happily busy for a week or two's lovely overtime, just right at this time of year.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    If you have an application written in FORTRAN that functions smooth as you like, easy to use, etc. etc. whose only downsides are: a) The hardware it runs on is obsolete and no longer supported, and there is no appropriate replacement, and b) despite needing minimal ongoing maintenance, you can't find any staff either willing or able to perform this task, then reluctantly you find you *have* to upgrade.
    Obviously. At that point, it's no longer a decision to rewrite/upgrade, but an imperative.
  • esteban (unregistered) in reply to Matt Westwood
    Matt Westwood:
    boog:
    esteban:
    Agreed, but tacking back to my original points, the decision to rewrite isn't necessarily a bad thing, if the app is insufficiently healthy.
    Agreed.
    esteban:
    That measuring stick is different for everyone, but if I heard an app was being gutted, (depending on context) I wouldn't necessarily assume mendacity straight off.
    Which I think is a valid point - we can be weary of rewrites, but we shouldn't assume outright that people are deliberately lying to push a rewrite.

    That said, I'm going to take the submitter's description of the legacy software as "easy-to-support" to be my evidence that the rewrite was probably unnecessary, regardless of motivation. There's no way for me to know for sure; the submitter's word is the only evidence I have right now.

    If you have an application written in FORTRAN that functions smooth as you like, easy to use, etc. etc. whose only downsides are: a) The hardware it runs on is obsolete and no longer supported, and there is no appropriate replacement, and b) despite needing minimal ongoing maintenance, you can't find any staff either willing or able to perform this task, then reluctantly you find you have to upgrade.

    And let me assure you, that's no laughing matter.

    Lack of institutional knowledge sounds like a very unhealthy situation. Doesn't sound like much fun at all.

  • (cs) in reply to boog
    boog:
    Matt Westwood:
    If you have an application written in FORTRAN that functions smooth as you like, easy to use, etc. etc. whose only downsides are: a) The hardware it runs on is obsolete and no longer supported, and there is no appropriate replacement, and b) despite needing minimal ongoing maintenance, you can't find any staff either willing or able to perform this task, then reluctantly you find you *have* to upgrade.
    Obviously. At that point, it's no longer a decision to rewrite/upgrade, but an imperative.

    But oh so sad. There's a beautifully written program whose only crime is to be written in a language which is no longer "fashionable", for fucking pissing vb asp microsoft sake.

  • foo (unregistered) in reply to Uncle Al
    Uncle Al:
    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.
    And this is of course retarded because the letters chosen for ctrl-keystrokes should only by coincidence have any relation to the underlying command names in the local language, yes?
    Like they do in the nonlocal(?) language? Ctrl-X = cut, Ctrl-V = paste, Ctrl-Z = undo. WTF?
  • Piotr (unregistered)

    Cool, Can you post full res picture? It will make super geek desktop background!

    :)

  • Sole Purpose of Visit (unregistered) in reply to RichP
    RichP:
    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.

    This one seriously merits a "featured comment."

    That opens up a whole new area of Type Theory. If your hierarchy can be modeled as a fractal, then 1700 classes is a mere bagatelle!

  • (cs)

    It looks more like a map of dependencies for the entire star trek franchise. (Was I not supposed to open that can of worms?)

  • (cs) in reply to Mmmpf
    Mmmpf:
    But see, when you turn the mouse wheel, it switches from WTF to Silverlight then Metro then WinForms then Telescript then back to WTF again. Nice isn't it?
    FTFY

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

Log In or post as a guest

Replying to comment #:

« Return to Article