5

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?

5
  • 16
    Frame challenge: how to deal professionally with a developer that does not listen to the expert? Or in other words, why is your assessment of what the appropriate quality is correct, and not that of your manager who is perhaps more in touch with the business's needs than you? – Philip Kendall Jan 18 at 8:54
  • 1
    It can be a catch 22, because you could in turn be criticized for creating bugs or low quality work. Finding the right balance is an art and a science. But there are also no-win situations, where you'll be criticized either way. – Mark Rogers Jan 18 at 17:34
  • 3
    "How to deal professionally with a manager that does not listen to the expert?" I'd start by not thinking of them as "jerk" for not agreeing with you. – Andy Lester Jan 18 at 17:44
  • 1
    There was similar tension at work when I was employed as a mas-producing jeweller, making products for the franchise-stores. I was paid to produce what they wanted, how they wanted, as quick as they wanted it - a certain quality of workmanship, BUT NO MORE. While I was asked what I thought, there was no real interest in my opinion about work processes. That's over 20 years ago now and I shudder to think what an ignorant pain-in-the-ass I was. KFC has strict requirement on size of their raw chicken. Bigger is not better - it sets up unreasonable expectations for the future. Uniformity... – enhzflep Jan 19 at 19:57
  • "The only thing they care about is Business." This is the only thing you care about, because it's the source of your paycheck. Tie every one of your arguments back into how it benefits the business, not how it makes your job easier or more "correct." – employee-X Jan 19 at 20:42
23

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.

7
  • 4
    +1 Management is supposed to know how good is good enough. Insisting that every bit of code a developer works on should be fully documented with 100% code coverage on tests and fully optimized is as silly as sending a grocery list out to be typeset and printed on fine vellum. Yes, upfront design and quality is an important factor in reducing sometimes hard to measure costs associated with supporting software, but it is easy for a developer to overestimate the incremental benefits relative to the costs of going that extra centimeter toward perfection. – ColleenV Jan 18 at 16:19
  • One of the foundations is project management and time estimates. Time estimates are usually inaccurate at the beginning of the project. As the project progresses, time estimates are more accurate. Good project managers keep in contact with the experts, about progress. The idea is that the stakeholders will be notified as soon as possible when the schedule digresses. This allows easier and faster recovery. Many managers don't do this, so project schedules digress and other issues pop up. Bad,very bad. – Thomas Matthews Jan 18 at 17:17
  • @ColleenV If you intend to use the same grocery list regularly, it is helpful to laminate it. I don't think that's a very strong analogy, since grocery lists are usually very ephemeral, and software rarely is. – employee-X Jan 19 at 20:38
  • 1
    @employee-X Lol, OK. My husband and I share a grocery list on our phones, so I was thinking “who bothers with a paper grocery list these days?” and you’re thinking, “Don’t just pay to have it typeset, laminate it because if you designed it well, it will be useful for a long time”. This is like a parable demonstrating why analogies are a terrible way to try to make a point. I will try to refrain in the future. – ColleenV Jan 19 at 20:44
  • 1
    @ColleenV I guess I'm not ready to give up on analogies! :-) – employee-X Jan 19 at 20:47
8

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

6
  • 11
    Option #3: It's not actually worth the increased development time to deliver "better" code. I've done any number of internal projects myself. Some done "properly", some done quick and dirty. Doing it properly added an extra month of development, and saved me only half a dozen bug fixes/incidents before the software was deprecated 3 years later. In other words: It turned out not to be worth it. – Kaz Jan 18 at 10:05
  • @Kaz It is true that there are times where it's not worth a better solution; but, nobody in software development can definitively say that a bad solution is good enough for this circumstance. We live in a world where a single damaging security breach can open up entire companies to multi-million dollar penalties; or, where a single security breach can do nothing for it's entire product lifecycle. I don't hold the crystal ball that tells me it's ok to not write a unit test for this method, do you? – Edwin Buck Jan 18 at 16:03
  • 1
    @EdwinBuck Nope, but it's an important factor to consider. – Kaz Jan 18 at 16:07
  • @Kaz Sorry, but you gave me a "no and yes" answer. If you disagree, don't do so halfheartedly. If you agree; but, only to bit of it, illustrate where we agree. Otherwise, stop playing verbal games. There are always times where quality is important; and, always times were quality is not taken to the extreme. We've seen billion dollar project (rocket launches) fail due to software bugs, and we've seen a letter not italicized due to software bugs. I would pay for tests for one of those scenarios; but, it's not always clear beforehand which one is the most impactful. – Edwin Buck Jan 18 at 16:13
  • 2
    @EdwinBuck No, I don't have a crystal ball. I was merely pointing out that there is a 3rd possible scenario beyond 'your boss doesn't appreciate the merits' and 'there are more pressing concerns' which is 'there are no merits to doing it in this case'. – Kaz Jan 18 at 16:44
5

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.

3

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.

0

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.

1
0

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.

1
  • +1 for the Do not compromise! You are responsible for code quality, take care of it, no one else will do. – IndianerJones Jan 19 at 14:12

You must log in to answer this question.

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