Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as off-topic by Ixrec, MichaelT, durron597, Snowman, TZHX May 29 '15 at 14:47

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Ixrec, Community, durron597, Snowman, TZHX
If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 18 down vote accepted

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.

share|improve this answer
This is definitely in the right direction. I just want to do it in a way that's not going to come off as "I know your wrong and I'm right" and still get something out of it. – Matt Phillips Jan 6 '11 at 1:21
@Matt: Then phrase it as "I don't know I'm right," and try your best to avoid making it sound sarcastic or accusatory. – Mason Wheeler Jan 6 '11 at 1:23
I'd use something like "I don't understand why this is done this way. wouldn't it be better/easier/cooler to do it that other way? i think it would also help with bug XX" – Javier Jan 6 '11 at 2:30
I think you might want to play with the wording a bit instead of directly saying "the right way to implement this would be Y". Turning it into a pure question "is there any reason why Y isn't used" gets the same point across without putting your foot down. Anyone will have a somewhat fragile ego when being questioned about their own code, and by appealing to their expertise (why did you pick X instead of Y) instead of challenging it (Y is/seems/feels better/cooler/easier than X) may elicit a more favourable response. – Steven Xu Jan 6 '11 at 7:04

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.

share|improve this answer

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.

share|improve this answer

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. ;)

share|improve this answer
"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!

share|improve this answer

protected by Thomas Owens May 29 '15 at 13:24

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.