How to balance quality and speed at work?

Question

I am a software developer.

The team I work on has over 25 people and we have multiple QA's (Quality Assurance), and Code Reviewers.

I mean this in the most humble way - I try my very best to write the best possible quality code and ask the Code Reviewers who I think are the most knowledgeable in the language/application I wrote in (our team handles multiple applications and not everyone is acquainted with all the applications) to get feedback, both for myself to improve, and for the application - to write bug-free code.

Sometimes, this leads to myself working on projects longer than anticipated for various reasons:

• Sometimes the proper way takes longer than a quick patch (this is pretty frequent)
• My project is related to previous projects (that are resolved), that have many bugs and I fix them along with my project.
• Code Reviewer comments/declines my code review request to make it cleaner, more efficient, etc. (as much as I have mumbled about this in the past, I am very grateful they put in the effort to improve and explain why my code is sub-optimal).

I am starting to see developers (I'm not sure if they're always, or they're starting to) - but they will spend less-than-anticipated time on their project (this looks great to upper management) but will always send their code review to a team lead/code reviewer who is not familiar with the language. I try to give them the benefit of the doubt but when I see their code, it's frustrating to work with because it's clearly 'whatever is quickest to make it work'- sort of style. And to be blunt, it's very fragile and prone to bugs. I think they're sending it to specific reviewers to have their code approved asap and get on to the next.

---

The reason I'm starting to have an issue with this is because my manager simply see's everyone's stats and is constantly praising them for it.

"So and so finished their 5 day effort project in 3, and does that consistently." I almost always take at least the anticipated if not more (our team has a tendency to underestimate projects but that's a different issue).

I find myself working a lot of overtime (we're salaried so doesn't matter) to improve the quality/remove bugs as much as possible but at the end of the day, I feel like my efforts go unnoticed and my stats aren't as good as coworkers who write quick/easy code to make it work for now.

I'm not sure how to voice my opinion on this, without sounding like '____ is writing completely garbage code.' and sounding arrogant and pointing fingers.

Personally, I know for sure that I do not want to follow their steps to increase my stats but I'm not sure how to

• Make myself not look bad relative to my team, to upper management
• Get good quality code approved

Answer 1

My project is related to previous projects (that are resolved), that have many bugs and I fix them along with my project.

Stop paying their debt. When you encounter a bug, write it up. If it doesn't block your work, move on. If it does, ask management for approval to fix.

This does two things.

First, management sees your timeline expand because you are finding, and sometimes needing to fix, other bugs. Versus now where you're perceived as just-plain slow.

Second, it shows management that other devs are doing shoddy work and not accounting for repairs in their estimates. Versus now where it looks like they are superheroes.

Answer 2

Management decides the balance, especially in banking.

Many people don't really appreciate that more carefully crafted code has fewer bugs. To many of them, new bugs are just unanticipated work that popped up out of nowhere rather than debt that was accrued and now must be paid off. In their mind, a quick implementation with a pile of bugs should be budgeted as 5 days for the original project and another 2 for unexpected work rather than 5 days for a good implementation as the other one was shoddy.

You also have to remember that even if your manager understands, will their manager understand? As your manager faces similar timeline pressure from their boss. A friend is on a team where this is the case. Everyone on the team knows that they are just turning tickets into bugs. But to the manager's manager, it looks like the team is frantically working to get everything done, which to him means that they are at peak productivity.

I'm not sure how to voice my opinion on this, without sounding like '____ is writing completely garbage code.'

So there are plenty of scenarios where this is completely true and also completely irrelevant. There are plenty of development teams where garbage earns a bonus and robust code earns a performance improvement plan.

Make myself not look bad relative to my team, to upper management

Get good quality code approved

I don't think these goals are compatible unless you are a much better developer than the others simply because they will (rationally) ship crappy code as that is what management rewards. I understand taking pride in your work, but you are also screwing yourself substantially here.

Banks tend to care about results according to whatever way they numerically evaluated on those results. Bank employees tend to do all sorts of shortsighted things to meet those numerical standards as to the bank, those standards are everything, whether it is accounts opened (with little concern for consent like Wells Fargo), derivatives sold (Lehman Brothers, with little concern for risk), credit cards pushed (no matter how many billions of assets managed it drives out the door, like at CIBC), or code assignments completed, like at your bank.

You are trying to fight the banking culture here.

Answer 3

All work is a series of compromises. There is a saying: "Good, Fast, Cheap. Choose two".

Sometimes the "best" workers are the ones that get the balance right. That may include shipping poor quality work that may come back to bite you later. Having said that, a lot of the time, managers think they have the balance right, only for a project to come crumbling down in the future, where the poor quality comes back to bite.

It's obvious to me from what you're saying is there is work getting approved that some senior people would not approve of. But you also suggest this is going on for a while.

This either means that the senior people are completely oblivious to what you categorise as a problem, or they are happy with the quality of the work getting submitted. If reviewers are giving their seal of approval on work they have little understanding of, then it's just not only those on the bottom of the rungs of the ladder that don't hold quality to the same regard as you.

Frankly, at this stage it appears that you have to make a decision if you want to be idealistic, or employed. Rocking the boat when seemingly ever other person is happy with the status quo would not be a good move.

What I would do

First of all, I'd make sure my work was in alignment with management. This may include sacrificing quality for speed.

Then, I'd start for form relationships with reviewers and team leaders. Try to get a movement going to ensure the best people possible are reviewing work. If these standards are established, all other problems should get brought to the fore.

If I felt like it was an very difficult uphill battle, I'd try to assess if I may be better working elsewhere.

Answer 4

I’m a manager in the banking industry in a group that has similar problems. I’m going to pretend like you report to me and tell you what I need:

• A sense of urgency to achieve the business objectives.
• If you don’t know what the objectives are, ask. (What drives our economic engine and what’s our mission statement?)
• Communicate all the time. Let me know what’s slowing you down and how it’s impacting the business objectives.
• If you see a problem, fix it. Don’t worry about job titles and don’t wait for permission, but let me know what you’re doing so I can redirect you if necessary.
• Don’t fear the quick and dirty solution. Document assumptions and risks and get it done.
• Help the code reviewers by reviewing your own code first. Point out compromises / risks, explain alternatives and your decision process.
• Don’t make code reviewers repeat themselves. Learn the standards, anticipate what they’re going to say, and make sure your code measures up.
• Embrace mistakes and fail fast. If you’re not sure, go with your gut, keep moving and keep learning.
• Seek feedback early. Sometimes it helps to write a quick tech design and say, “here’s how I intend to solve the problem”. Whiteboards are great if you’re in the same office.
• Write code in small batches. Code doesn’t have to be “done” before you start getting feedback via code reviews. Just be clear in the comments the code isn’t done and where you’re seeking feedback.
• Communicate status once a day at a minimum, including the next few steps, ETA on finishing those steps, and blockers.
• Absolutely write unit tests. If you don’t have a lot of experience with unit tests, don’t let yourself get bogged down in complicated set-ups. I’d rather you only test the code that’s easy to test and at the same time learn how to make code easy to test.
• Resist shipping code you know is broken, but not too hard. Document what’s broken, including what it will take to fix, and let stakeholders make the call.

In a nutshell, I need you to keep churning out output while feeding me and others information. That allows me to go to my bosses and say: Look, my team is working hard and they’re focused on the right things. We’re not going to get any more productivity by pushing them harder. However, when we look at quality and efficiency, there are lots of opportunities to improve, and they have some great ideas. Jett, in particular, is someone I’m leaning on to lead us out of this mess.

Answer 5

It's clear you work with a bunch of cowboys, you aren't going to change that. Their motto should be "We haven't got time to do it properly, but we've got time to do it twice."

But stop fixing their mess for free unless you have to, and if you have to then make sure it's documented somewhere.

Answer 6

People are talking here about what management might want, which is an appropriate answer for your current job. I'd like to take a twist on the question, talking about your personal assessment and what you might want, esp. few years later. I am taking it in a sense from my perspective, as I did a lot of programming in my life, too.

Find your type

There are very different kinds of programmers. Some love prototyping. Some like fleshing out the minor details and polishing up things. Most of us can do anything. In fact, in a smaller project (or in a pet project) you may find yourself doing everything from architecture to maintenance.

But it's in your own interest to find what are you doing best. Often it coincides with what do you like most. Knowing your strong side you can move towards it in future projects – or even in your current job. Try to change your role so you would do more things you like.

Yes, I know, this sounds trivial.

But think again. You like writing quality code and dislike tight time constraints. It might suite you better to be moved to some core backend tasks, where quality matters more. If, say, you like prototyping, but do not like polishing things, some kind of R&D fits you more. Say, evaluation of different approaches, prototyping, what not. If you like fixing bugs and don't like writing new things, request a move to a maintenance team and buddy up with testers. You get the idea.

Basically, your question reads "how to balance things I like to do and plumbing I like less, but which needs to be done". My suggestion is, in the same essence, "try doing more things you like and less plumbing you dislike". It might not help you at your current workplace, so you might want to save this for your next job search.

Answer 7

The problem relies on these:

Make myself not look bad relative to my team, to upper management

• Delivery of the projects, if the project/task has been delivered on time or ahead of time even how much it was so bug prone, to the higher management who knows nothing about the backend process, this will become a really good work for them. Management will always see the output, not the quality. And for not to look bad in your own team, don't push your ideals to them unless you are in power or they are an open person.

Get good quality code approved

• One of the main reason why those quick/fast codes has been passed through that hole, are these code reviewers who knows a little bit of the proper coding standard. Like for example in my case, there was a developer that been assigned to us as automation tester to review our codes when pushing it, but this developer does not really understand how to make a really good working codes as well, so what happened was that, my other co-workers (same automation tester but first time doing it) have codes that I don't think that on the later on will be good, got accepted. And after awhile these code become a problem, but that code reviewer did not become responsible on what he approved of. My point is that, the as long it does not give an error on their part, they usually approve it, especially if there is a time constrains. Unless you will become code reviewer or have a power to push things, it will be hard to push your own opinions to them.

I find myself working a lot of overtime (we're salaried so doesn't matter) to improve the quality/remove bugs as much as possible but at the end of the day, my stats aren't as good as coworkers who write quick/easy code to make it work for now.

• I assumed that you will do these without no one told you to do so, since your stats aren't as good as your coworkers who wrote it. Well it is good to take initiative but if no know's that these codes are not good in the long run, no one will realize it. So stop what you are doing, and try to focus more on your task instead. Try raising it but don't change it to improve unless you are being told to. They will not see the need to improve the quality, unless your application will broke because of it. It is bad but advice, you need to make them realize in order for them to start caring.

Answer 8

The core problem is that your manager doesn't care about code quality, because they have no incentive to do so. Therefore the first question must be: can you incentivise them to care, e.g. by keeping track of hours wasted reworking fast devs' bad code?

Unfortunately I'm going to guess the answer is "no". I'm also going to guess your manager is a non-technical buffoon who uses dev estimates as metrics they present to their managers, and smaller = better. In other words, they have zero reason to care about code quality, because fast-but-bad-quality code impacts them positively. As such, the manager also has zero incentive to change the fast-not-good devs' behaviour, because that behaviour benefits him/her positively.

Essentially, the manager and fast devs are a group that will actively block your attempts to increase code quality. Because they are a politically powerful group, you won't be able to go through them; you have to go around. You're unlikely to be able to do this alone, so the question then becomes: are you able and willing to build up your own group that prioritises quality over speed, and has more political capital than your manager's group?

If the answer is no, you need to either choose between giving in to and becoming one of the fast group, or finding another job.

If the answer is yes, then build up your group and start gathering evidence among yourselves as to the effect (wasted time and money) that the fast devs are having. Once you have enough evidence (political capital), present it to your manager. When your manager ignores it (because of course they will) present it to their superior with the information that it has been ignored. Assuming said superior actually cares about not wasting money, things will likely change pretty fast after that.

Yes, this is extreme advice; but speaking from experience, this is an extremely difficult battle you're contemplating. People like your manager, who choose fast over good are almost always people who choose easy over right, and as such getting those sort of people to choose right (quality) willingly is near-impossible. If you aren't up for such a fight, your options are again - accept the status quo, or move on.