Comment On Enterprise Dependency: The Next Generation

boog:

frits:

It's a map of Europe!

Not a map, just an artistic portrayal; it's abstract.

I am Zunesis:

This looks like my latest outbreak of HPV.

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.

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.

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.

Rosuav:

steenbergh:

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

Preservation of sanity.

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.

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.

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.

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.

Severity One:

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

Rosuav:

steenbergh:

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

Preservation of sanity.

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.

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?

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.

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.

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

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.

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.

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.

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!

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?

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.

esteban:

Just because an app gets rewritten, doesn't mean the bogeyman is out there.

esteban:

People make technology choices for lots of reasons, good and bad... Whether it gets rewritten well or not is the question.

esteban:

If the legacy app in this case was pristine nirvana, then by all means, the rewrite was pointless.

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.

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.

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

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).

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?

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.

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.

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.

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.

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?

Mmmpf:

boog:

frits:

It's a map of Europe!

Not a map, just an artistic portrayal; it's abstract.

Europe is abstract too.

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.

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.

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.

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.

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.

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?

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.

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?