I feel you're judging the programmers a bit harshly. Unfortunately, even if one makes one's objections known in discussions (if there are any to start with, this depends on company culture), there not always taken into account.

You start from the assumption that managers and senior designers/programmers will listen to reason and follow common sense arguments, which unfortunately is not realistic in all cases.

Personally I've been lucky in this respect, and, judging from your post, so have you, but I'm afraid it's a mistake to take it for granted.

Just my 2 cents, -gjb-

Update: Well, being nearly fired counts as being lucky in my book.

Although I've never met Abigail, I'm pretty sure I speak for him (and most others) when I say we have not been similarly lucky. I remember nearly being fired when pointing out the deficiencies in a given design. (And, I'm sure it was part of the reason why one of my contracts was ended early.)

And, there's no reason why you have to follow the designs given, if they're stupid. If I was a programmer on that project, I would implement my own DAOs and write it that way. Then, when my one piece has good performance with the ability to choose which DAO to use in a given situation without impact ... results speak for themselves much louder than anything else ever can. (I've done this method, too.)

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Although I've never met Abigail, I'm pretty sure I speak for him (and most others) when I say we have not been similarly lucky. I remember nearly being fired when pointing out the deficiencies in a given design.

I don't know whether it is "luck", but I have succesfully rejected specificiations. It was almost 6 years ago, and I had just switched from the release management department to the technology department. For my second project, I had to implement "two-way replication", together with my cow-orker Mark. Mark and I had just finished a course about replication, and we didn't have much experience yet. The spec was written by Ruijin, a very capable programmer with years of replication experience, and our CTO. Ruijin decided to leave the company, which is why I had to do her work of implementing the spec.

But in stead of sheeplessly implementing the spec (which would not have been hard as the spec was clearly written) I decided to first study the problem, the constraints and the spec. After a week I had not only a couple of testcases that showed the spec would result in data corruption, I also had a correct (but a far more complicated) way of solving the problem. I consulted Mark and another cow-orker and they agreed with me. I went to the CTO, and told him that I thought the spec was wrong, and that there was a different way of solving it. He pointed to the whiteboard and told me to explain my case. I did, and afterwards, the CTO asked Mark if he agreed with me. After Mark answered positively, the CTO gave me the go ahead and I could implement my solution.

Abigail

In this context, being "lucky" means getting away with having your own opinion and acting consequently, not everyone is in such a luxury position. Nearly being fired is not being fired, it's an unpleasant experience, but has no consequences when compared to actually being fired. A contract that is terminated early is no disaster either if you can get another.

What I mean is that it is fine for the likes of you and Abigail-II to speak your mind: you're good programmers who'll manage to find something else if the worst comes to the worst. Both of you seem very competent, so if you think some design is flawed, chances are quite big that it actually is.

But again, this is my point: most programmers are not that good. If they get fired, it's not easy to find a new job nowadays.

Another important point: I wouldn't like to work with lesser gifted people who simply ignore the design since they're a liability to the project.

A last point: when you're working in a team, you're supposed to play by the rules. Not many people will tolerate that you go solo, and again, when less accomplished programmers are involved, with very good reason.

Don't let your own competence cloud your judgment about these matters. Just my 2 cents, -gjb-

It all depends on how the company defines the responsibility of each role. It would be unfair to sack a person, if one’s role even does not allow/give the opportunity to question.

Theoretically, if some one with a higher rank approved your coding or design, you now holds much less responsibility on your own, instead the approvers are the main focus. If approval is just a signature with no responsibility and risk, it is too easy to be a manager, and the organization will not roll.

I agree with you that the designer should be sacked/demoted, as he is not capable. In this case, programmers are innocent, first they were not given opportunity to question, and secondly I don’t think the company expected them to have enough knowledge to question. (I am not saying that they really didn’t have the knowledge, what I am saying is that one should not be blamed for not delivering, if they were not responsible for delivering.)

Theoretically, if some one with a higher rank approved your coding or design, you now holds much less responsibility on your own, instead the approvers are the main focus. If approval is just a signature with no responsibility and risk, it is too easy to be a manager, and the organization will not roll.

I've worked both in US and European "corporate cultures", and I've often been asked about differences. This is one of the differences I often point out: the American tendency to avoid responsibility, and to look for a scape goat. As long as I've a signature of some manager, I'm safe. Or Yes, I know it's foolish, but he's senior management, I'm not going to question him. I think this is also the reason why in the USA there's less initiative coming from the 'lower ranks' that it happens in Europe. Perhaps that's why workers in Europe have the same productivity as US ones, while working far less hours.

Abigail