Quality vs Development Time & a jerk Manager

Question

Quality vs Development time

As a developer I like to deliver quality. This means thinking out an sensable architecture, reading docs (in case of integrated a new package to the code base or when learning a new framework), developing, configuring, writing tests, inspecting code, code reviewing, improving after review, bug fixing, fine graining code, deploying and so on. This development prices takes time.

I believe that my speed of development is 'normal'. It is always possible to do the development faster (and slower).

Managers

My experience is that managers/CEO's have the tendency to not care about quality. The only thing they care about is Business.

"You are a bit slow"

My manager told me that "I'm a bit slow", he added that I must crank up the speed. I told him that developing with quality takes time. I added that a sacrifice in quality will take more development + bug fixing + calm down angry customers time in the long run. However, he insisted that I need to speed up.

Question

How to deal professionally with a manager that does not listen to the expert?

Answer 1

How to deal professionally with a manager that does not listen to the expert?

You're not the only expert here.

Management are trying to balance the quality of the product against the time it takes to ship it. Until the product ships, the company doesn't get paid. And they need a regular income to pay everybody.

So it's a delicate balance between developing a perfect product and finishing it too late and shipping a buggy product the customers will hate. Your manager thinks you're too far towards the "too late" end.

Answer 2

I agree with you 100% on the importance of well designed, carefully crafted, reliable code. However, there is only so much you can realistically do to enforce that since it is your manager's job to decide how your implementation process is going to work.

There are 2 possible scenarios...

1. Your manager doesn't see the merit of unit testing, design etc. In this instance, you can continue to point out the benefits of a best practice approach or the potential future costs of cutting corners. However, don't over-do it (you don't want to be that guy) - if he remains unconvinced there comes a point where you need to accept he makes those decisions and learn to live with it.

2. There are external, more pressing concerns dictating the pace of delivery You need to keep in mind that the development manager attends meetings without the team and so typically has more complete information. There may be external factors of which you are not aware driving the pace of delivery. For example, if you want to beat a competitor to market with a new feature or a customer has threatened to find a new vendor if X does not happen by a given date. Equally, it's possible that his manager is applying pressure on him and, despite him making the same case about quality, unit testing etc., is being told to deliver more quickly. (A good manager will communicate at least some of that information to the team - but that's obviously not always the case).

Answer 3

Imagine you take your car to the mechanic because it's having some engine problems. The mechanic gives you two options.

Option A: Thorough fix, $300, the fix won't be done for two days, but it shouldn't require rework.

Option B: Quick & dirty fix, $100, the fix will be done later today, but it will fail and you'll have to bring the car back in a few months to do Option A anyway.

Which one is the right choice? The easy answer is "of course, you do option A". But what if you don't have $300 right now and you can only afford $100? What if you have to have the car back tonight for some reason, and can't afford to be without the car tomorrow? What if you do have $300, but you have other things to spend money on that you deem more important?

You make your car repair decision based on the best information you have. The mechanic gives you the options and the information to make the decision, but lets you make the decision, because you're the customer.

---

Similarly, it's not your job to decide your company's business priorities. If management decides, for example, that getting the project done by a given date, even if it means cutting corners that they'll pay for later, that's OK. You might not agree with it, but that's OK because it's not your decision to make. Your job is to present options that management can choose from, and let them make the decision.

If you're not comfortable doing the work that they're asking you to do, then find another job where you can do the work you want to do.

However, no matter where you go to work, you're going to run into situations where the people paying the bills and paying your salary are going to make choices that you don't like. Maybe they decide that the project X you're working on isn't as important to the company as project Y, and they scrap project X and move you to project Y.

On the plus side, if your boss decides that project Y is more important, but that proves to be a bad decision, it's not your fault. Not overreaching your level of responsibility can be very freeing.

You're going to run into this over and over again in your career, no matter what your job is. I suggesting getting used to it or you're likely to be pretty unhappy in the long term.

---

P.S. You say "The only thing they care about is Business." That's right. That's their job. Nobody is paying you out of the goodness of their heart. They're paying you to do a job that makes money or saves time for the business. If the work you do doesn't do that, then there's no need for you.

Answer 4

The most important thing to assess in a job is how you are being measured.

Your company probably has a bad metric that is being applied; something like lines of code per day (or week). You can rightfully tell them that their metric is bad; but, they won't listen to you because you're on the wrong side of the metric. Instead, they'll hear "I couldn't make the metric, so I'm saying the metric is bad."

At some point in time, you're going to have to decide if you want to improve the company or go elsewhere. The main problems with improving the company is that in order to gain the trust within the company to effect change; you have to become part of the problem you wish to change. You cannot become a trusted partner in the company by arguing the company is wrong.

First step, figure out the actual metrics you're being evaluated on. Second step, be a beast and outperform on those metrics. Third step, get promoted into a place where you start providing input that can steer the company. Fourth step, slowly modify the metrics into something better.

I worked at a massively popular web control panel company. It prized programmers based on how many cpan modules they were involved in; and, the number of lines of code committed to git repositories per day. Never mind that most of the code that was submitted was then reverted, and that unit tests were still being discussed as "a waste of time, because they pay you to program, not to test". My personal story goes from being presented as a superstar to being fired six months later. It's not easy to try to improve a company.

Good luck, you'll need it.

Answer 5

Your question is "How to deal professionally with a manager that does not listen to the expert?"

I submit that is the wrong question. Your question assumes that you know better than the manager. However, it is their job to know about the business issues. It is your job to give them the information they need in order to manage your efforts correctly according to the business needs. The real question is, "what information am I missing about this situation?"

Secondly, if you are being criticized, your manager does not see you as the expert. The political question is, "who does your manager see as an expert in the department?" To survive in this political situation, go to that person and ask how you need to be changing what you do. If you can get the department "expert" to guide you, you will go a lot further. If you disagree with the department "expert", I suggest that you find another place to work.

Now, I have been in a situation where the manager was not managing the relationship with the client properly and it got out of control. Those are situations where the only survival tactic is to put everything in writing and manage the client and the project to the best of ability - until it is time to bail out and find another job.

Answer 6

As a software developer you probably take pride in the product. It has to be a quality product, except for maybe the occasional one-time throwaway program that you build, right?

The manager is not that much different. What is very different is your definition of "one-time throwaway".

For the average developer, work is a team effort. We rarely program anything alone. We constantly build on the achievements of others and we have little competition for jobs. If you strive to be a senior developer, it does not matter whether Alice in your team is a senior developer already. If you are both good enough, you both get to be senior developers. If the pay is right and the team is nice, you would not mind staying with the company for years. What you build now, you will probably need to support when it's done. If you don't support it, some other developer will, that you might just as well be friends with. They are on the same team. You would feel bad to leave them a pile of crap. If someone else has to maintain it, you would be proud if that person said "what a nice and hassle-free application".

For the manager, that world is as alien as it gets. You work alone. You have subordinates, you have bosses. Your peers are not your team, they are your competitors. Their success is a disadvantage to your career. You might like your boss, but it's a pyramid, for you to get promoted, they need to go. Preferably by getting promoted themselves or retiring, but any other way will do, too. As that is not likely, your career plan involves not being in this company for longer than it needs to secure the next better job. Maybe 2-3 years. What you leave to your successor is none of your concern. You moved on to greener pastures, that person after you is a competitor anyway, no friend of yours and you owe no professional courtesy. What they say after you are gone does not concern you. They'd not praise you anyway, because again, they are your competitor.

Obviously, the agendas of the developers are better for the company than the agendas of the managers. But both are supported and confirmed by the default company. Well, by the company's managers anyway, so that's slightly biased.

So with this in mind, lets refocus on the "one-time-throwaway" again that does not need good quality. For you, that is something you need only once. A rare occurrence. For your manager, that is everything they do. Because they will be gone in an average of a year. If you do it sloppy and there are a lot of bugs that will haunt you in the next five years... it's a big deal for you, but no problem for the manager. They won't be there in 5 years. Or even 3. Even if bugs pop up the day after release, the normal assumption is that developers did something wrong. The manager did not write any of that code.

There are two ways to get out of this:

• Work for a really good manager. That is hard to find. One way to get rid of all the agendas is work for a company that is small enough (or the hierarchy is flat enough) that you work for the company owner. Owning a company removes the need to see anybody in that company as a competitor. It removes a lot of the "politics". I know the owner of the company has exactly one agenda: produce a good product and make the company successful in the long run (if they were in it for the short run, they'd not be owner, they'd be CEO somewhere).

• Do not compromise. Do not tell your boss that you need 3 weeks for programming and 2 weeks for testing. I had my boss tell me to my face that I just needed to "program better" and we could save on the two weeks of testing. I will not elaborate, but obviously that's stupid. So do not tell how exactly you work. In that example you need 5 weeks. Period. If it's needed to be delivered faster, ask what you can leave out. Which requirements can be skipped or postponed. Offer a way forward for your manager. But do not compromise on quality. Nobody else does.