9

I work for a mid-size company and have been there for more than a year. I am part of two teams (TeamA and TeamB). TeamA has 15 members (14 teammates and 1 manager) and TeamB has 3 members (2 developers and 1 manager). Both the teams have different managers. Majority of my work is done in TeamB. My manager is TeamA manager but i report to TeamB manager as well because i spend 90% of my time working for TeamB.

The problem i am facing is that every time we have requirement to develop something, we will discuss the design. In almost every design meeting, the solution given by me will be turned down because it requires more coding effort and little complexity. For example: In one situation, we had to categorize the items. My solution was to have a table with Categories and another link table that will hold Category-Item relationship. This was turned down because it required creating two tables (Category and CategoryItemLinkTable) and we ended up hardcoding the Categories for each item in the Item table. Reason given to me was that "We will hardly ever change the categories for an item once they are set. And if we do, we will just replace it in the code everywhere." There were many occasions when there was no reason to not like the solution but just because they did not like the idea.

I also noticed that the other developer and the manager will kind of team up against my solution and will oppose it which will leave me no choice but to feel like "I should have just kept my mouth shut and not come up with anything and do what is told."

I like the place i am working at but i am little confused as what am i doing wrong. I prepare design documents, create mock-up solutions and demonstrate it but still it gets turned down for some reason that hardly can justify it.

Can someone please guide me how do i deal with situation and over come this problem?

Improve this question
10
  • 4
    It's the manager's job to care very much how much code will be written.
    – Dan Pichelman
    Dec 6, 2013 at 17:58
  • 4
    Joe the example given is less complex and less risky than having to modify hard coded values in multiple places in the code.
    – Neuromancer
    Dec 6, 2013 at 18:10
  • 2
    @Asdfg - "When you design the solution, you need to keep it open and not close it" - that actually goes against advice I read (I think from Phil Haack) which said "the first time you do something, it's fine to hardcode it. The second time you do it, you can hardcode it again. If you find yourself doing it a third time, then it's time to look for a generalized solution." If "closing the solution" makes development faster, then that could be the right decision if it's not likely that it'll change.
    – Adam V
    Dec 6, 2013 at 20:05
  • 3
    @Asdfg - I don't see evidence for "my manager is not being rational". I don't even see evidence for "favors other peers". I only see evidence for "I'm unable to convince him to put in extra effort and complexity now for a theoretical gain later" (as MrFox's answer states below).
    – Adam V
    Dec 6, 2013 at 22:19
  • 5
    Your manager might be making a perfectly rational decision to incur increased technical debt later in exchange for something else now based on business requirements that they either know and you do not, or that they attach a greater importance to than you do. As I've worked my way up in seniority in my IT career, I've learnt to recognise how much of a pain in the ass my younger, more naive self must have been to my managers back then. Sometimes quick and dirty is the answer. Sometimes "good enough" really is. Sometimes, of course, it isn't but that's the manager's call to make.
    – Rob Moir
    Dec 16, 2013 at 10:49

5 Answers 5

Reset to default
20

Either your solutions are not as great as you think they are, or you are not presenting them very well. Keep in mind, decision makers always weigh cons and pros, they do not necessarily value any intrinsic properties of a system. So any 'correct' design by comp-sci standards are meaningless, unless they can be represented in the context of:

  • Work hours; present or future
  • Productivity lost or gained; present or future
  • Bugs created / fixed
  • etc.

When you're presenting a solution, make sure to also bring up the real material benefits that will come from your approach.

...Which leads me straight into the second part of my answer: are you sure your designs are best in the context of the business needs? In my experience, programmers tend to prioritize ideological purity, or some sort of theoretical correctness above the bottom line. They get taught to do that by academia and all these evangelical authors of technical books. But this is disingenuous towards the business, the business only cares about the final result.

Take your example, where the manager wants less lines of code and a simpler DB design in favour of hard-coding. Yes, hard-coding is theoretically a bad idea, but if the probability of it ever changing is next to nil, and they know the business well enough to make that estimate, then it might be the right approach. The benefit of their solution is less code to write, less code to maintain, less things to test and less things that can go wrong. It's an absolutely valid decision in some contexts.

So my suggestion to you going forward is:

  1. Analyze your design ideas in the context of business value. You might find that your initial intuition is wrong for the situation at hand.
  2. If not, present your ideas with the backing of business value.
  3. If and when your ideas are rejected, understand the reasons for the rejection. Keep these reasons in mind next time you are doing step 1.
  4. Finally, don't think of ideas as 'my idea' or 'his/her idea'. This leads into all sorts of ego problems. Think of them as "Approach A" or "Approach B", and try to learn why it is that the company you are in keeps taking a different path than you expect.
Improve this answer
4
  • If i take your answer as it is then there is no need for anybody to learn/understand Design Patterns, no need to spend time architect the solution. Just let the manager decide and go from there because he "knows the business" well. I completely disagree
    – Asdfg
    Dec 6, 2013 at 19:43
  • 9
    @Asdfg then you have misunderstood my answer. You should use design patterns when appropriate. When is it appropriate? When it adds business value (which is most of the time). So if programming with design patterns makes your code more maintainable and easier to debug then those are the arguments you should use. However, if your design patterns are just intellectual masturbation that needlessly complicates the code base, then it subtracts business value. Regardless, at the end of the day all that matters is business value. The style of coding is a means to an end not an end in itself.
    – MrFox
    Dec 6, 2013 at 19:51
  • While this is a good general purpose answer, in the software development environment it is actually considered bad practice to hard wire things like category names into your source code. Those things need to come either from a database table OR from a configuration file. You may also catch flak from the ISO 9000 dudes if they ever decide to inspect your work.
    – Captain Kenpachi
    Dec 9, 2013 at 12:22
  • 5
    I once spent a lot of time arguing why we shouldn't spend ages creating a really abstract model that could support any cloud based storage for files, when we knew which one we were going with and it was very unlikely to change. When it does change, that's the point to invest the time in abstracting it and using better design patterns. Some design patterns are definitely a waste of time in some situations.
    – Fiona - myaccessible.website
    Dec 10, 2013 at 12:02
6

I don't know what ratio you expect or the amount of suggestions you make, but you don't mention the 10% they accept. Maybe those have something in common the rejected ones lack?

You need to realize you're asking to make changes in the way things are being done.

  1. The further away from the norm your suggestions are, the less likely they'll get accepted. Start focusing on small changes.
  2. Have evidence of the problems caused by previous practices. An example of someone having to go back and change the same code/data in multiple places and missing a few is a good arguement. Maybe this caused a bug in a program and caused a lot of customer support calls or got the manager in trouble.
  3. Make sure you recognize other people's solutions. You don't want to be the person who disagrees with everything, so no one takes your side. Bad reputations and impressions can be formed in only a few instances.
  4. It's not a contest to see whose ideas get used the most, so stop keeping score.

Being there over a year may not be enough with this company to be recognized has have a high enough level of authority. You may need to be more patient.

Improve this answer
4

My suggestions are turned down around 95% of the time. That's fine, and I'm perfectly happy to be wrong. I make suggestions I'm almost positive are dumb regarding difficult questions because quite often it leads the discussion to a clearer result.

You're not there because you're right 100% of the time - you're there to have input on the process. Don't feel bad about people rejecting your ideas.

The one thing I ask when my ideas are rejected: Why? If they can't give me a reason why their idea is better than mine, I have a problem with that.

In summary: Keep offering ideas unless asked to stop.

Improve this answer
1
  • One of the best ways to learn is to speak your mind and get feedback.
    – user8365
    Dec 6, 2013 at 22:50
1

There are two things to address here.

  1. Whether your suggestions 'should' be accepted
  2. Dealing with the repetition of this scenario

2 is much more important than 1

tl;dr: step back, be strategic, break the cycle with input from B

Why does this keep happening?

I find the most frustrating things are those that recur without seeming to improve. I quickly see them become Sisyphean and lose heart. But the change does not need to be that you give up and become like all the other peons.

Your suggestions may or may not be appropriate - there is often more to consider than the immediate technical challenge, and often I've been wrong when I didn't know or didn't take into account other considerations. What's more important is progressing from here.

You need to talk to boss B about this repeating scene. Request a meeting with him/her, take them to lunch, whatever. You will need to be calm and receptive, not combative and defensive; your quest is to begin to work with B towards a point where 50% of your suggestions are accepted. This conversation is the only way you will find out whether there are prejudices against your suggestions (e.g. because you are younger, or more junior, etc) - you may not be told it directly, but you will be able to analyse the responses to your questions to see whether there is a plain reason or not.

Should my suggestions be accepted?

At one end of the spectrum, your suggestions could be the optimal solution to the problem in every case, and it is only some blind prejudice or stupidity making the rest of the team disagree. At the other end of the spectrum, your suggestions are all way off, and you are wasting everyone's time. Both of these are unlikely, even though your emotions may want to polarise toward one or the other (it's easier to respond emotionally with either the superiority or inferiority complex).

More likely is some combination. If, like me, you were the junior member of the team but better at seeing solutions to technical problems, then you are probably getting a little discrediting for being junior, but also missing the mark more often than you realise. Other considerations that you may not be taking into account are the YAGNI principle (Ya Ain't Gonna Need It), which is the counter to endless boilerplating, over-complicating things by adding layers of abstraction which won't pay off, or sometimes by assuming that the constraints you are given are more important than the time you spend solving the problem (it's tempting to try to look brilliant by meeting all the constraints, but letting complexity grow significantly in the solution).

This is a learning experience - some of your solutions will be technically wrong, which you will usually learn in the discussion. Some will be wrong from a management perspective - too much complexity, too much time to implement, difficulty of maintenace, reducing future flexibility. Some will be rejected in error. Some will be rejected in prejudice.

Since spending ages going through your suggestions may take a lot of time, particularly if you have a lot of them, I would suggest you ask to meet periodically with just B to improve your approach; in these meetings you will be able to get a more frank statement from B on why suggestions weren't selected, and more importantly get general guidance. You'll note this also gives you an opportunity to show how good some of your solutions are, which may increase the chance of futures ideas being accepted.

Change your approach

I used to be the thirsting upstart, ready to take on the world with my skills. I was rather less amazing than I imagined, but more important was a change in approach. Take everything as a learning opportunity, and try not to react emotionally. It took me a few years to stop taking it personally when my ideas were not accepted, or were shelved for a rainy day.

You need to approach the team strategically. Remember the cardinal rule of employment, you are there to make your boss(es) look good. That doesn't have to be your personal goal, but know that it is the crucial factor in their view of you. So keep detailed notes of your ideas so that you can highlight later (in a private meeting with boss B) how your suggestion would have been appropriate. Maintain a good relationship with boss B and meet with B to work on improving the success ratio; understanding better why your ideas are being rejected will help you both focus on the right things and not suggest things which won't be accepted.

Some answers here are essentially 'you're right, they're wrong' - great for the id, useless in practise. Others are more 'they're right, you're wrong' - great for the ego, and inferiority complexes, and useless in practise. I'm asking you to take a step back, and accept that they're right on some counts, you're right on others, and there's a lot of grey area where neither the situation is much more equivocal. I think this is much more about your relations with the team, and your relationship with yourself. You are not above them, nor should you be quiet.

Improve this answer
0

Get a 1-on-1 discussion with the manager and ask him directly.

Are there personal issues?

Should you change the kind of suggestions that you give?

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .