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

Sounds like you had the right combination of corprate culture and the ability to argue your point well. There usually isn't much you can do about a company's culture, but I think argueing correctly is something more programmers (including myself) should learn.

When the boss sends out an e-mail saying that by next week, your entire web site must be converted to using MS Access as a backend, it's easy to run down to his office and tell him that he is a bloody fool. That is also what you absolutely must not do. It'll likely get you fired, no matter what your company's culture is like.

However, if you take the time to come up with a solid case, covering (for instance) how Access doesn't allow concurrent database connections and what that means when you have anything much more than 100 hits/day, you've done your job. Depending on the culture, they might still fire you--if they're that dumb, they probably did you a favor. They could ignore you, in which case you've done everything you could, so it won't be your head when the web site falls to peices (especially if you left a paper trail of your suggestions).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

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-

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.

I, on the other hand, don't like to work with people who don't want to take responsibility, and don't speak up when they think the design is wrong. Or even worse, people who don't think about the design at all, and just accept it as is. Even if their ideas are incorrect, at least they show commitment and the ability to form independent ideas.

Abigail