Comment On Enterprise Dependency: The Next Generation

A while back, I posted The Enterprise Dependency and then Big Ball of Yarn. They were both visual depictions of a good ole' enterprise framework that was "several dozen megabytes chock full of helper classes like IEnterpriseAuthenticationProviderFactoryManagementFactory. So, continuing in the tradition of the Representative Line, here's another representative dependency diagrams offers some insight into the pain that large applications' maintainers face each day. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Enterprise Dependency: The Next Generation

2011-11-17 11:32 • by D-Coder
367143 in reply to 367132
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 11:37 • by 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!

Re: Enterprise Dependency: The Next Generation

2011-11-17 11:45 • by 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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 11:50 • by Could I Bother You to Recharge My Zune? (unregistered)
367146 in reply to 367131
I am Zunesis:
This looks like my latest outbreak of HPV.
No you are not.
...but thanks for minding the store for me.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:05 • by Daid
367147 in reply to 367090
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:11 • by frits
367149 in reply to 367145
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

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:18 • by esteban (unregistered)
367150 in reply to 367142
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:20 • by Silfax
367151 in reply to 367095
Rosuav:
steenbergh:
Why can't I click on it for a full-sized version?


Preservation of sanity.


Bigger than the dimension we live in.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:39 • by boog
367153 in reply to 367150
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).

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:41 • by C-Octothorpe
367154 in reply to 367150
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:50 • by Mason Wheeler
367155 in reply to 367122
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:50 • by Captain James T. Kirk (unregistered)
367156 in reply to 367134
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

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:52 • by Jay (unregistered)
367157 in reply to 367086
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.)

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:54 • by Jay (unregistered)
367158 in reply to 367095
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:54 • by Matt Westwood
That's really beautiful. Looks like an artist's impression of trees in the snow, as seen through a light winter mist.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:55 • by Kuba
367160 in reply to 367102
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 12:59 • by Jay (unregistered)
367161 in reply to 367117
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:00 • by Marnen Laibow-Koser (unregistered)
367162 in reply to 367160
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...

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:02 • by Kuba
367163 in reply to 367138
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).

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:04 • by Matt Westwood
367164 in reply to 367128
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?

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:13 • by boog
367166 in reply to 367156
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:25 • by Uncle Al (unregistered)
367168 in reply to 367164
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?

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:29 • by boog
367171 in reply to 367161
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:36 • by no laughing matter
367172 in reply to 367161
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!

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:46 • by frits
367173 in reply to 367172
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?

Re: Enterprise Dependency: The Next Generation

2011-11-17 13:50 • by boog
367175 in reply to 367173
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

Re: Enterprise Dependency: The Next Generation

2011-11-17 14:03 • by 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...

Re: Enterprise Dependency: The Next Generation

2011-11-17 14:24 • by esteban (unregistered)
367178 in reply to 367154
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 14:28 • by r66 (unregistered)
367179 in reply to 367117
I am sure, the generation after "the Next Generation" will seriously question this name choice when they start their next-generation-rewrite.

Re: Enterprise Dependency: The Next Generation

2011-11-17 15:09 • by boog
367180 in reply to 367178
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).

Re: Enterprise Dependency: The Next Generation

2011-11-17 15:16 • by JayC (unregistered)
367181 in reply to 367160
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 15:27 • by DaveK
367183 in reply to 367127
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!

Re: Enterprise Dependency: The Next Generation

2011-11-17 15:36 • by esteban (unregistered)
367184 in reply to 367180
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 15:41 • by picard (unregistered)
so, the number of classes [nc's, or NCC] is over 1700.

like 1701?

enterprizy

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:02 • by Matt Westwood
367186 in reply to 367168
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 ...

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:27 • by boog
367188 in reply to 367184
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:29 • by coyo (unregistered)
367189 in reply to 367127
<blockquote>
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.

</blockquote>
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.<br> I have seen 10,000 line long functions, which is way beyond too much. <br>
I've also seen messes of things so abstracted the code is just a mess of message passing single or double line subs.<br>
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:32 • by Bob (unregistered)
367190 in reply to 367128
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:37 • by Nagesh
367191 in reply to 367164
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!

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:42 • by boog
367192 in reply to 367137
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:48 • by Matt Westwood
367193 in reply to 367188
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 16:51 • by Matt Westwood
367194 in reply to 367189
coyo:
<blockquote>
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.

</blockquote>
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.<br> I have seen 10,000 line long functions, which is way beyond too much. <br>
I've also seen messes of things so abstracted the code is just a mess of message passing single or double line subs.<br>
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:08 • by boog
367197 in reply to 367193
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:21 • by esteban (unregistered)
367199 in reply to 367193
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:23 • by Matt Westwood
367200 in reply to 367197
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.

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:24 • by foo (unregistered)
367201 in reply to 367168
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?

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:25 • by Piotr (unregistered)
Cool,
Can you post full res picture? It will make super geek desktop background!

:)

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:30 • by Sole Purpose of Visit (unregistered)
367203 in reply to 367116
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!

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:32 • by PiisAWheeL
It looks more like a map of dependencies for the entire star trek franchise. (Was I not supposed to open that can of worms?)

Re: Enterprise Dependency: The Next Generation

2011-11-17 17:33 • by Silverhill
367205 in reply to 367100
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
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment