Images That Strike Fear In A Developer's Heart

Thursday, August 23, 2007

Anytime you open up a design tool, and see something like this ...

... you know you'll need stiff drink at the end of the day. It doesn't matter if the boxes represent tables or classes – it's a complicated mess. In this case, the screenshot is from a Visual Studio 2005 Analysis Services project.

Anyone have some aspirin to spare?


Comments
Anonymous Coward Thursday, August 23, 2007
Hey, it's the windows OS class diagram
Moz Thursday, August 23, 2007
Yes, scary. When I started my current job I ran an automated tool to build a class diagram. I mean, it's a non-trivial project, it's useful to see how it all links together.

On a standard page, the diagram is solid black. Not so much because there's a lot of classes (700), but because there are so many linkages and there's no way to arrange those to not look like a mess. Everything just links to everything. In every possible way: inheritance; encapsulation; references; interfaces, you name it.
rtw Thursday, August 23, 2007
Q: What do you need when the program/database is structed like that and you don't have a design tool available.


A: A .22 and 1 bullet
Jens Thursday, August 23, 2007
OKAY, you're going to need a stiff drink. But when I look closely, I see a cloud with 7 to 8 central blocks, and a lot of the other blocks only link to those center blocks. It seems that this is a model of an application that does 7 to 8 things. Something like a mini ERP system.
The question is if there is a way to develop an app like that without ending up with a class- or data-model like that. I'd like to hear your thoughts about that, as I'm working on an app that is heading the same way.
scott Thursday, August 23, 2007
Jens:

The idea in your scenario would be to reduce the coupling between classes (modules, services, pieces of functionality) in the ERP system as much as possible.

I'd look at design patterns and tools that can give you inversion of control and dependency injection. Keep the modules as isolated as possible so that a change in A doesn't ripple into B, and both A and B can be tested in isolation.
Eric Sowell Thursday, August 23, 2007
You know what scares me worse than that? Starting a new gig, opening up a sql diagram with all the tables in the database, and seeing NO lines because they don't have any foreign keys in the db. THAT'S scary.
Jens Thursday, August 23, 2007
Scott,

I know that the idea would be to reduce the coupling, what I really wanted to know was how much less edges should there be on the diagram before the fear starts to disapear ?
After all, there is only so much coupling you can eliminate.
Moz Friday, August 24, 2007
I'm a big fan of trees instead of nests. If you can keep things linking either up or across but very rarely both the whole system is easier to maintain. Admittedly I tend to leave data carriers out of that analysis, and in code use records/structs for that task so it's obvious which is which.
scott Friday, August 24, 2007
Jens:

Well, there will always be edges. I guess the answer would be "it depends".

If you can program to abstractions (like the interface IOrderService) instead of concrete implementations (OrderService) than it can help to keep these different modules/services/areas of functionality loosely coupled.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!