Is it just me?

Hi All.

I've just got kicked off this god-awful contract, and it was hell!

Look, I get Interfaces, and I get Generics. I get Inheritance. But dammit, code should be maintainable!!! It's no good rooting around for a couple of hours trying to find where this damn object is getting its behaviour from! What's the bleeding point? And when you have interfaces inheriting off other interfaceS (plural! - I didn't even know you could do that?!) in a non-trivial application can you imagine how difficult it is?

The architect has forms - he calls them `gui`s - inheriting off generic classes, off generic interfaces, and the like:

vb.net Code:

Partial Class Form1
    Inherits SomeDamnClassGui(Of T)
....
End Class
 
Public Class SomeDamnClassGui(Of ISomeInterface)
    Inherits Windows.Forms.Form
    ...
End Class
 
Public Interface ISomeInterface
    Inherits ISomeOtherCottonPikinInterface
    Sub MustDoThis()
End Interface
 
Public Interface ISomeOtherCottonPikinInterface
    Sub MustDoThat()
    ReadOnly Property WithThis() As String
    Property ToThat() As ICollection(Of IYetAnotherDamnInterface)
End Interface
 
Public Interface IYetAnotherDamnInterface(Of T)
    Sub ScreamOutLoud()
End Interface

This is because he has two other layers: he calls them `renderers` and `helpers` which are used to display the `gui`s, because, in his architecture, forms - er, `gui`s - don't know how to display themselves!

So, the helper goes to a worker, which goes to the data layer, which tells the worker, which tells the helper which tells the renderer which tells the gui how to show itself! And what is meant to be the payback for this convoluted fiasco? Maintainability!!

You got to be kidding me! Maybe I'm a crummy programmer after all, but I couldn't make heads or tails out of this sushi mush. Why not call forms frmThis and frmThat, so that we can tell them apart from ucThis (usercontrolThis) and ucThat; or txtSpecialThis - which even a newbie would immediately suspect is a textbox?

And when I asked the moron, what's the point of this convolution to the database, he said, indirection! WHAT THE HECK DO YOU THINK A DATASET'S FOR??

And bear in mind - I wrote it down - there are 92 projects in this solution, 781 classes and 67 interface code files (there are up to a dozen interfaces in each code file!!!)

Over the weekend, I decided to tell the agent that I wanted out and sent her an email. I called this morning and she said she'd look into it. This afternoon I'm called into the managers office and told to bugger off, because I'm incompetent! I hadn't done this; I hadn't done that! I was more than half again as slow as the next slowest consultant. Yada yada yada!!

Yeah. I'm sure it had nothing to do with me calling the architecture demented!

Or is it just me?

Wow, do you know what the problem is there, the guy is one of these purists who thinks EVERYTHING should be an abstraction of everything else. Buy him a copy of code complete and tell him to take the test at the back.

There is a class of people who believe in form over function. You got all of it. Technically, there are only two solutions, one is to document the holy heck out of everything. The other one involves explosives.

However, I have to object of your misuse of the word sushi. The finest food known to man shouldn't be maligned by using it as some kind of adjective like thing.

Ah, so it isn't just me! Thank goodness.

Codedfire: I'd prefer to take him to the back of the room for a knuckle sandwich! :mad:

ShaggyHiker: I meant no offence. But how do you find the head and tails in sushi ;)

And here. If I'd seen the clown's code ahead of time, I would never have taken the job. Is it alright to ask to see a sample of the work being carried out in an interview? I would love to ask in my next interview. It would have saved a lot of heartache on this occasion.

Why has he made it sooo complicateted though, his he of the older persuation?

Quite the opposite. He was taken on last year as a contractor, and has stayed on as a perm. He and two other youngsters (I am far older) had, apparently, full run of the house. The project is now overdue and HAS to be out by May.

I think what happened is quite simple. As lead architect (with a bunch of shiny new reference books on his desk) he and the boys decided to `go for it`, program the max out of the solution using all of the `latest` techniques. Without an older, more experienced guide to `curb his enthusiasm`, it all just got out of hand. What seemed like a good idea at the time is now a nightmare of twisted goings-and-comings; thus the requirement to take me and another guy on. (By the way, this other guy is sneaking off to an interview today Tuesday, so who knows how long he's going to be up for the ride?)

I would go as far as to argue that he doesn't really get the technology. My first task was to create a usercontrol with four buttons on it. He then had me implement an interface on this. In other words, although we now had a resuable control, each form on which an instance of this control sat had to implement the interface.

Yes, this means that every form hosting this control can be called polymorphically, but, get this, each form has its own caller (renderer), so what the heck is the bonus in being able to call the forms polymorphically?

It is like creating a master key (the interface) to a bunch of locks (the usercontrol instances) and then copying the master key all over the place (the individual renderers). Why bother with a master key? Each lock has its own key, so where's the frigging benefit? Innit!!!

Sounds like he decided to re-architect parts of the .Net framework. Why the render methods and whatnot when they already exist?

I love interfaces, inheritance and other OOP paradigms but he took it soo far as to re-invent the wheel.

This is shameful. Ok il admit im not exactly the most experienced (hell i might be the least). But what he is doing is blantently insane. Ive read about splitting a program into layers, bussiness and logic for instance but that was it. The idea of this was to abstract the data being taken from the UI from itself. IE each layer was idepentant of each other. This would seem to me to make sense.

But why in gods hell does he have for instance a renderer layer? maybe im just not skilled enough to understand these concepts fully but i see no reason for many of the layers and interfaces that he has.

I presume management have an almost working program and dont care how it works as long as it works. Its funny our till system in work is kind of like that. Everytime it breaks someone rights patch code and thats all the bloody think is no a huge mess of problems and patches!

I always ask how much documentation they have if I'm considering a contract on pre-existing architecture. Also ask what their coding standards are. If they haven't documented anything even a simple Spec document to define the application then you can bet its going to be a nightmare. If they are not using any coding standards then its going to be even worse. When I end up in these types of situations I usually start back at the beginning writing the specifications and then go about re-writing their code without telling them that is what I'm doing. This can be hard to pull off with some psycho who is so proud of his work that he keeps the master copy on his own machine and his idea of source control is people asking him for permission to work on it. If it is actually going to get completed though a re-write is often the only way. Plus if I'm going to put my name on something and take responsibility for it then it is going to be done to my standards.

been there, done that, burned the t-shirt, and had you been on this side of the pond i'd have thought you worked with the same blighter that tried to do that here :)

So, it baffles all of you as to why someone would do this. I had a discussion with my teammates about this once. We have some simple systems, and we have some overdone systems too. Same kind of code, where you end up with 22 layers of abstraction to deal with a single string.

There are several reasons that a person creates an application in this way.

1) I like to call this the "What-if" syndrome. "What if we don't want to use a file called web.config, what if we want to use a file called garden.gnomes?" So this leads to configurable configuration managers. Then, "What if we don't want it to be called <connectionStrings>, why not <gardenGnomePants>?" And a configurable configuration managing configurator is born. There is, for whatever reason, an innate tendency to make everything as configurable as possible instead of concentrating on the more immediate issues.

2) This is known as the "I'm better than you" syndrome. Developer1 creates an architecture. Implements it. Developer2 joins later and looks at code.

Quote:

---

Developer2: This code is so difficult.
Developer1: What's the matter?
Developer2: I'm having trouble understanding it.
Developer1: Oh, you don't understand it? Why, I understand it perfectly. It all makes perfect sense to me. I must be really intelligent.

---

3) I call this the "Peer Fear" syndrome. Someone in a team implementing a certain architecture may feel that something is being done in a wrong way. However, in order to avoid ridicule by his peers, he does not complain. He simply complies and goes along with what the team is doing, while there may be other members who feel the same way and simply don't want to appear stupid in front of others. Programmers are by nature egotistical and patternal pride is very important to them. How dare you suggest a 3-tier architecture when we have 9?

Having said all this, I am having trouble believing you about there being 92 projects in the solution. Perhaps you are doing this to get attention from us. Because at some point, even the most syndrome-afflicted architect will realize that it has gone too far. I might believe that it didn't start off with 92 projects but started off with a lower number and accumulated over time.

Perhaps you were right in wanting out, but how is someone else going to view this? They may think that it was rather unprofessional of you. Have you found your next job already, what will you say when they ask you why your previous contract ended early?

Quote:

---

Originally Posted by kasracer

Sounds like he decided to re-architect parts of the .Net framework. Why the render methods and whatnot when they already exist?

I love interfaces, inheritance and other OOP paradigms but he took it soo far as to re-invent the wheel.

---

kasracer: man, you're prescient! even he used to make fun of himself saying, `i like to re-invent the wheel: you know, make it rounder`. I laughed at the time; I ain't laughing now :(

SHAEFER: I might have mentioned it below, but maybe not. The fact is, the project is now in trouble and they've GOT to put it out by MAY. That's why me and the other fellow were brought in. There's no cotton-pikin' time to re-write anything. And NO documentation. Not poorly documented. Not little documented. UN-documented! But as a contractor, I attend interviews several times a year. I have always been wary of asking too many questions, and coming off as combantant. However, I think I am now going to be very up front, because its best not to get into a crummy job. How the heck am I to account for the time I've spent with these clowns now in my CV? I can't give them as technical references - they've said I'm incompetent!!

CodedFire: The need for the renderer layer eluded, and continues to elude me. The worker layer, at least, equates to a business layer, but I never did get the renderer layer.

DirtyHowi: I could have used lead-lined boomerang on Monday ;)

mendhak: I SWEAR to you I'm not kidding. (And by the way, I never said it started out with 92 projects. I wasn't there when the project was started, because there is no way I'd have been party to that architecture. I only joined the company two weeks ago.) The code will eventually be released as a web service. I am quite willing to tell you the name of the company and the name of the product, I actually had to sign a confidentiallity agreement, and they can sue the pants off me for disclosure, but I don't think this sort of information counts as a breach. If you wish, I am prepared to use this forum's private messaging facilities to provide you with that information. Furthermore, there have been two highly insightful comments made today; the first by kasracer, and the other by you, when you said, its for configurability. This is EXACTLY the same thing the guy was always saying: `we're doing it like that because we might want to extend it like this, or like that. It means we are not tied down to any particular implementation.` That is very nearly a direct quote.

The reason I wanted out was for fear of what exactly transpired: blaming me for incomptence for being unable to penetrate impenetratable code. No, I don't have a job to go to, and as I have worried above, this is obviously a contract I am not going to be able to mention in my CV... I'm not happy about that, but what else can I do?

No, I don't want you to break any laws out of spite, so we don't want to know what company this is.

I believe your quote. I've heard it before... not being tied down to one implementation. But of course, it still means work to do in the end when there's a new implementation to be 'implemented'. :D

I'll be honest with you, and don't take this personally. One of our projects has around 12, I thought that was bad. But now I can think of you and feel better.


OK, but frivolity aside, that's pretty huge for a web service. I'm not an architect (yet) (hope to be one some day) but it's pretty obvious that a web service, especially a public facing one, isn't something that will change all that much. It may have additions, minor modifications, but the underlying structure stays the same. You'll use one database, you won't suddenly decide to switch over to XML files and carrier pigeons. Sounds about right.

Anyways, do you feel you'll be able to get another job? Will you write it off as a vacation you took for a while?

Also, here's another one. You might know this already, but maybe I should mention it... "Don't burn your bridges". You really never know when you run into them again or when you need them. I can understand where the frustration stemmed from and that was indeed a difficult situation to deal with. Perhaps I would have ended up doing the same, but for now, I am sitting in this-here armchair, and things are easy for me to say.

Hi mendak.

These are not large projects. If you, me, dupree or anyone else was the architect, we would, for instance, place a custom textbox, custom checkbox and any other custom controls into one project. This fellow, on the other hand, would place each each one into a seperate project. As you have already noted, this is so that it can be re-implemented without necessarily changing anything else. And don't forget that the renderers each had their own project, as did the helpers, the `gui`s and the workers...

No matter what I thought about the architecture, it is a blow to the ego to be kicked off any project. I hold my hand up and tell the truth, the whole truth and nothing but the ugly truth: my confidence has taken a hammering.

In fact, this is something I'd like to solve once and for all: just how do I get an objective measurement of my skills? Microsoft Certification? Some other kind of professional skills measurement?

As for getting another job, I suppose one will turn up eventually, but this is not a good time to be out of work, here in the UK. The credit cruch coincides with the end of the financial year. However, hopefully, things will start looking up towards the end of this month.

Finally, I did everything to avoid burning any bridges. That is why I called up the recruitment agent, to give her enough time to find someone else to take my place. This may or may not have precipitated my dismissal; taking the employer at his word, he had already decided to `let me go`, as they say around here. But, on the other hand, if I ever go into an interview and find that architect fellow sitting there, I shan't be bothering to hang around...:cool:

To everyone with "over architected" system.... you have my sympathy.... to a point.

When I was first introduced to the new .NET architecture of our app (which is now a quasi-VB6/VB/NET hybrid - and not the good kind of hybrid that gets us 80 miles to the gallon) I felt the same was. It was a HUUUUGE paradigm change for me. "Wait, wait, wait. Let me get this straight.... I have to do WHAT jsut to make a simple sproc call? You're krazy!" ... but now that I have been working with it intensly the past couple of months, I see some of the beauty of it. The old system relies 100% on SQL Server. And all of the processes run on the client. With our new 27-layered approach (that's how it feels sometimes)... we can actually have parts of the system off load themselves to an app server. Different app servers at that. Hellooooo scalability. It also allows to be able to configure the system to use a different database than just SQL Server. Hey there Oracle, mySQL! It also gave us the opportunity to implement data auditing right into our business objects.... Sarbanes-Oxley compliantcy, here we come! Just with those three elements alone double our market potential, to the point where we have a couple of Fortune 100 type companies looking at our software. And as strange as it seems, we have actually lost a couple of potential clients simply because we were still using VB6 and the system could scale well.

Even with all that.... we've only abstracted just to the levels we needed. We've got some custom UI elements in our app.,... but they are all in the same project at least.

I'm sorry that they didn't even try to show you the reasons for what they did. There's jsut no excuse for the lack of documentation. That's pretty jacked. that and the fact that they didn't have the time to teach you the system.... disaster in the making. Probably jsut for the best you got out of there. There's no way anyone can plop into a chair at a company and hit the ground runnign at full speed.

-tg

hey there, tg.

look, i have sometimes known that i've over-architectured a solution - usually just to push the boundaries of my own knowledge, rather than strictly for the client's sake. and i think it was mendak who pointed out below that for a web service, the project i'm referring to is going something heavy.

besides which, even if you have a gazillion layers, why can't we use a proper naming scheme, so that we know what the heck the object we're working with is?

and, even if you have a gazillion layers, do you REALLY need to tell a form how to render itself? if the renderer is on one application server and the form is on another, are you confident that you haven't sacrificed one heck of a performance hit for `scalability`? and if the renderer is always going to be on the same server as the form, then why is it split in the first case?

maybe its just me, but when we go from 3-tier to n-tier, i really have a great deal of difficulty believing the extra tiers should be anywhere but in the business and/or data layer. splitting the presentation layer, which is what this fellow had done to the nth degree, just strikes me as bonkers.

also, as i pointed out earlier, one of the main arguments for this spaghetti code was `maintainability`. well, how's anyone going to come in off the street and maintain this mess? i might not be as good a programmer as i think i am, but i can't believe i am a complete duffer either. if it is going to take the average joe a couple of months just to get the hang of the app, then really what has been gained in the meantime?

in the most complex application i've worked on until this last, there were several of us on the team; it was a large 3-tier application which took us 8 months to write. i am happy to say, anyone could go in now and get the hang of most of it within a week or so, without having someone holding their hand all the time. now surely, that's maintainability?