How to convince my boss to improve code quality? [duplicate]

Question

The place I'm working for is a service provider. We have a lot of services, which are written to deal with deadline, so their code are really terrible:

• No coding convention, everyone codes in his own style
• No unit testing (which is really bad)
• No refactoring (which is truly worse)
• No automation build/deployment

etc

and these code are used again and again, so bad code continue to spread all over my department.

I really want to set up a standard quality for our code, by requiring everyone to follow "rules": every line of code which does not follow convention will be rejected, and every function of code which does not pass unit testing will not be committed,...But I don't know how to convince my boss to allow me to do this. I'm relatively new comer, so inspiring people from my works is really hard, and I think it's easier if my boss support me to this.

Thank you very much for your advices

Answer 1

I would not start from your boss. I'm sure other developers in your company are equally concerned about your code quality: sit down with them during lunch break, discuss the issue and agree on a shared style guide.

Work with the new coding conventions for some time, then present your results during a meeting: "together with [brave comrades], we started using these conventions [link to a specs file]; it really improved our productivity and it makes it easier to distribute tasks and spot bugs during code reviews".

Chances are that the decreased code convention entropy, together with soft techniques such as eagerly reviewing more orderly merge requests, will be enough to lead your remaining coworkers on the right path.

Shouldn't this work out, you'll have gathered enough empirical data to show your boss how a consistent style leads to more stable, more understandable software - and you might propose the style check as a merge prerequisite.

If she agrees, you can repeat the process for the other issues you mentioned - I suggested the tackling the coding style first as there is no extra upfront expenditure.

Answer 2

Explain to him about technical debt and why it is important to keep it in check by doing "down payments" all the time. If you don't, you'll have to spend all time paying the rent and not getting anything done.

I really like that metaphor since it speaks directly to their wallets.

Answer 3

It's all about cost to benefit. Most management fails to see that by putting in some time, effort and money up front to develop these things in their development groups can reward them with lower costs later. They only plan for immediate costs and take the quickest, cheapest path for the immediate moment. Trying to change that mentality in most business environments takes a lot of time and effort and demonstration after demonstration of the financial benefits of these new approaches until it finally sinks in.

Answer 4

The only good way to convince management to do or not do something is to show how it affects the bottom line.

You and your team and/or technical lead need to show how coding conventions, unit testing, and automated build/deployment tools will save your team time or improve productivity. In order to justify spending time refactoring, you need to show how spending n hours now to clean up existing code without adding new features will save m hours of implementation and debugging later (where m > n).

Answer 5

I think you might need to remember that the goal of your company is probably not to generate beautiful or perfect code. Personally, I think that coding standards (especially strict ones) are more of a micromanagement tool than a useful contribution to the quality of the application. In most situations, coding standards should be extremely minimal.

For example those that argue that having a standard for whether the opening brace goes on a newline somehow increases code readability somehow silly. Consistency is nice, it looks pretty, but can you really argue that it actually creates any additional value to the organization?

As for refactoring: That is just one of those things that it is simply better to ask for forgiveness than permission. Do they actively prevent you from refactoring as you go along? Really? Often I see developers waiting around for a stone tablet from the mountain-top to employ good coding practices like refactoring when they just need to go do it. If your boss is looking over your shoulder and slapping the back of the head when it looks like you might be refactoring, THEN there might be an issue. I've rarely seen a shop, though, that the programmers don't have enough autonomy to do it on their own. Just remember to include time for it in your estimates.

Unit Testing: If the lack of unit testing was creating major quality issues, then I don't think you'd have a hard time selling it to your boss. If it isn't then why are you complaining? Just suggest it, make your case and go on with your life.

The bottom line is that you will need to make your case in terms of the bottom line for the company. All of the things you suggest are just a means to an end, and that end is an application of sufficient quality to meet the needs of the users. If you can't find a justification in terms of problems with the current releases (either quality or time to deliver) then you might consider that you are obsessing on your tools instead of the work product. If you CAN find justification in terms of the final deliverable, just point to those complaints and their cost to the business and tie them to whatever coding practice you can offer that will remedy them.

Bottom line: Don't try to turn your problem into your boss' problem. Take one of his/her problems and explain how you will solve them with better practices.

Answer 6

Perhaps you are trying to do too much in one step. "every line of code which does not follow convention will be rejected,", could be pretty intimidating for people who are used to the freedom to do it their own way. I also suspect it sounds too controlling, short pieces of code with few interactions with other systems don't need a high formal level of software engineering, and it probably isn't cost effective to apply SE too deeply.

Maybe, incremental improvement of the firms SE environment/culture is more feasible. Find some relatively noncontroversial reforms, and let their worth become apparent, then push for the next step.

Answer 7

That depends ;)

How is your history of delivering products? Do you deliver the desired functionality on time, in a stable product (by stable I mean, do the end users who cannot see the terrible things going on inside perceive it as stable)?

If not, I would ask my boss, if he is satisfied with the product that you are delivering. If he is, I would find another job. But most probably, he isn't. And then I would enlighten him that there are processes that can ensure those things.

Answer 8

See Steve Mcconnel' The Business Case for Better Software Practices and Software Development’s Low Hanging Fruit.

The first shows productivity, schedule and defect improvement.

Companies that invest in post-gold rush development practices have found that their investments pay off. In 1994, James Herbsleb reported that the average “business value” (roughly the same as return on investment) for 13 organizations that had taken on systematic improvement programs was about 5 to 1, with the best organizations realizing returns of 9 to 1. In 1995, Neil C. Olsen reported similar returns for organizations that had made significant investments in staffing, training, and work environments. In 1997, Rini van Solingen reported that the average ROI was 7 to 1 with the best organization realizing returns of 19 to 1. In 2000, Capers Jones reported that the return on investment from process improvement could easily go into double digits (i.e., returns greater than 10 to 1). A recent analysis by Watts Humphrey found that the ROI for improved software practices could be in the neighborhood of 5 to 1 or better...

The second has "LHF [low handing fruit] that will Not be Resisted by Upper Management" that lists Coding Standards, Daily Build and Smoke Test and Test-First Coding, three issues you asked about.

Steve McConnell describes strategies that produce improvements in schedule, quality, and development costs in the short term. McConnell identifies the specific technical practices that produce the highest returns on investment, the lowest risks of adoption, and the shortest paths to more successful software projects. McConnell describes the theory behind short-term vs. long-term improvement strategies and presents tips for maximizing your chances of success in adopting these strategies...