After reviewing the transcript you posted earlier, here's how I'm interpreting the conversation:
- you suggested a change of requirements to your boss and described your rationale
- the boss said no and didn't provide a rationale in return that would satisfy you
- you continued to press the topic during later conversations, but the boss held their ground
- you became frustrated because the boss didn't accept your solution but also didn't explain what's wrong with it
- the boss became frustrated with you forcibly continuing the discussion and refusing to complete the assigned task
I can see several topics here that I'd like to address separately:
You shared your concerns and provided an alternative course of action
This part is good. Keep it up 👍 Looks like you're a programmer - sharing concerns about a spec is (well, should be) part of your work. Sharing concerns is a special case of informing people. Keeping people informed is generally a Good Idea.
In this case, you're informing about a possible alternative course of action related to this particular project. In order to make your information as valuable as possible, make sure to emphasise the expected benefits. (TBH I think you did a fine job of that - one thing I'd add is your best estimate how much of a time save we're talking about when comparing your solution against the original one.)
Your boss refused and you didn't accept the assignment
Decision making can be implemented in various ways. In this particular case looks like your boss is acting as the decision maker for this project while you'd prefer to make design decisions by consensus. This mismatch can be unpleasant for you - sorry! There might be some ways for you to affect this part of the process in the long run, but before that happens, a good course of action is to work according to the existing process. Your boss expects that you'll follow their lead and implement their decisions, even when you disagree.
The technical term for this is "Disagree and commit", look it up!
Please also bear in mind that the boss might have a reason to refuse - maybe they have more context about the project, or know some requirements (or possible future requirements) that you don't know? Ideally they would explain it to you, but this didn't happen (sorry!). Maybe they would have to go back on their word about how the project's going to look like when delivered? Maybe they estimate the communication overhead of a spec change to be larger? Maybe something else?
Yes, there's a possibility of the boss actually being wrong, but it's the boss who's accountable for the results, so it's their role, not yours, to make the call here. Your role is to give them all the relevant info you can.
footnote: It might make sense to veto a decision and escalate in some situations, for example when your work ethics are being violated ("I won't do this because we would lie to our customer") or if the company's interest is at risk ("if we deploy without this bugfix, all hell will break loose"). A (potentially) sub-optimal design decision is nowhere as severe in my book.
You expected an explanation from your boss but you didn't get one
This one is not about your boss or your project - it's about you. Looks like you carry an expectation that your boss will make technical decisions in a transparent way. In a case like this, you'd like to hear why your proposal has been rejected.
I think you're being reasonable - I have similar expectation towards my boss, and it's important to me for several reasons such as:
- I need a possibility to learn while working
- I need to feel I'm respected and being taken seriously
- I'd like to have an opportunity to contribute to architecture, not just implementation
If my expectations are not met, I won't develop professionally as much as I'd like to, and I will be unhappy and less productive at work.
(You should be able to formulate your own list like this!)
In this situation, it seems worthwhile to go and say exactly that to your boss given an opportunity. This will give your boss some context and hopefully lay a foundation for some improvements to how the two of you work together.
My advice would be to avoid discussing this in the middle of a technical discussion, and instead schedule a 1-1 meeting where you can comfortably discuss your expectations towards each other and your mode of work, in a larger context than just one isolated case (just use it as an example).
Bear in mind that in such a conversation you won't be demanding things, you'll be making a request. Be kind, stay respectful, don't try to judge your boss while in the meeting. Focus on communicating your point of view and your expectations clearly.