Dealing with a fundamental design flaw when you're new to the project [closed]

Question

I've just started working on an open source project with around 30 developers in it. I'm working on fixing some of the bugs as a way to get into the "loop" and become a regular committer to the project. The problem is I think I've uncovered a fundamental design flaw that's causing one of the bugs I'm working on. But I feel like if I blast this on the mailing list I'm going to come off as arrogant, and some of the discussions I've had about the issue are butting heads with some of the people. How should I go about this?

Answer 1

Even if you're pretty sure that this is a "fundamental design flaw," remember that you're an outsider. It could be in there for a good reason. Or, depending on how old the project is, it could have been put in there for what was a good reason at the time and now it's still around for historical reasons.

Instead of "blasting this on the mailing list," try asking a question. Something like:

"Hey, I just ran into X, and it doesn't make any sense to me. It seems like the right way to implement this would be Y, but then again I know I'm new here and I don't want to jump to any conclusions. Is this a mistake in the design, or is there something I'm missing? Can someone fill me in? Thanks."

Engineering is one of the few places in the world where humility is still considered a genuine virtue, and asking questions about "obvious problems" this way is a really good way to get good answers and learn new stuff.

Answer 2

One of the 48 Laws of Power:

Win through your Actions, Never through Argument

Any momentary triumph you think gained through argument is really a Pyrrhic victory: The resentment and ill will you stir up is stronger and lasts longer than any momentary change of opinion. It is much more powerful to get others to agree with you through your actions, without saying a word. Demonstrate, do not explicate.

This is one I've learned the hard way after many pointless arguments.

In this particular case, I'd advise coming up with a very simple and specific piece of code that should work but won't because of this design flaw. As the old saying goes, "You can't argue with the compiler/interpreter".

The other thing is that to have influence over a group, you have to be perceived as a member of the group. Even though you've joined the company, people don't perceive you as a member of the group yet. Thus, it might be better to go along with the established group until they learn to perceive you as one of them.

Answer 3

Could you inquire as to why a particular design was used? That way you may get more of the back story as there may be some good reasons why something was chosen that you don't know. I'd go with the idea that you aren't quite the expert that can pick apart the design but inquiring may be a way to learn more so that eventually you could ask about that flaw you found so that the message won't be seen as flame bait or trolling.

Answer 4

You probably won't like this...but, here goes...

I'm working on fixing some of the bugs as a way to get into the "loop" and become a regular committer to the project. The problem is I think I've uncovered a fundamental design flaw that's causing one of the bugs I'm working on.

No, no you didn't. If you did, you wouldn't be so hesitant about it. The fact that you yourself are not sure about the "fundamental design flaw", means that you haven't discovered one. When trying to point out somebody else's mistake, it doesn't buy you any friends to use superlatives (like "fundamental").

What you may have discovered is a slightly better design, for the issue you're having. You should probably test it thoroughly, though - since you're new to the project, there's a better than even chance you have no idea what you're talking about.

But I feel like if I blast this on the mailing list I'm going to come off as arrogant

Calling it a "fundamental design flaw" will definitely come across as arrogant. For that matter, even pointing out that it may be a bug isn't the best idea. If you don't know for a fact (and can back it up) that it's a problem, then you need to humbly ask questions and research until you understand it completely. Better than whoever you're trying to convince.

...and some of the discussions I've had about the issue are butting heads with some of the people. How should I go about this?

Stop. This isn't a moral issue, and it's not killing anybody (I assume). If you intend to be a long-term member of the project, you must first earn trust before questioning them. Fix the bugs, do an amazing job of it (by whatever metrics the group values), design a few features, and earn a seat at the table.

Then, without pointing fingers or calling anything broken, humbly bring up a suggestion to improve the design to the group. And you better have thought through all the consequences and the solutions to them, or you'll be shot down for being "naive". Be ready for an argument about why your design is better. Be prepared to lose, and lose gracefully.

If your idea truly is better, it'll either be eventually accepted by the group (though perhaps not by the original designer), the group doesn't care, or the group is stupid. In either of the latter cases, why would you want to be a part of the group, anyway?

...

If you're capable, the alternative is to just code the damn thing up so bloody brilliantly that they'll tremble in amazement at your coding prowess and have no choice but to accept the elegant simplicity and eternal truth of your design. Developers do respect competence, but you have to be careful - the punishment for incompetence (or unwarranted arrogance) is rather severe. Since you're asking this question, though, I'm guessing the brilliant and unabashed arrogance route is not really an option. ;)

Answer 5

"Hi thanks for welcoming me into your home. As I walk through the door, I want to let everyone in the family know that their baby is ugly and somebody dressed him funny."

A bug is a bug, and it's ok to call it that. Saying that it is caused by a "design flaw" is pointing a finger at the guy before you (most likey the "daddy") and telling him he's an idiot.

Unnecessary and counterproductive. I suggest:

"In regards to issue #blah, I think I can fix it by doing X Y and Z but I'm not sure how that will impact the rest of the project. Would this be ok?"

Where X Y and Z correct the problem. Let them tell you it was a design flaw; there may be an alternate solution. Or the assumptions behind the 'flaw' may run so deep throughout the project that changing it will fix the bug but break everything else!