Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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

share|improve this question
3  
Straight-forward reasons do not always work on management; you often need to bring in a lot of buzz that other "smart & powerful" people are buying into. The latest hit has been agile and scrum. You have to sell a story of up to 5 x performance at some company elsewhere because of XYZ. Finally, when you are given a green light to use XYZ, then do whatever you think needs to be done. Managers cannot be told, but they can be brainwashed. If selling Scrum fails, try selling 6 sigma (and again justify some of your activities by it). If you fail at this, then beef up your resume and quit. –  Job Jan 15 '11 at 16:46
    
@Job: It is a bit sad but what you say happens quite often (5 x performance increase!). Very good comment. –  Giorgio May 2 '13 at 18:37
add comment

marked as duplicate by gnat, Jalayn, MichaelT, BЈовић, GlenH7 May 3 '13 at 0:08

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

8 Answers

I would not start from your boss. Aren't there two/three people, besides you, who are reasonable? Get them to sit down during lunch break and try to decide for some conventions to follow.

Work with the new coding conventions for a week, then write to the boss together with the other two/three reasonable people: "we started using these conventions (link to a specs file); how cool is it that our code is way easier to read? How about we all use these? Think about all the time it takes for new hires to get productive: it will be halved!" and stuff.

If he accepts, you'll have gained enough contractual power to push the other issues. If he does not, or if there's not other employee who follows you into the "coding standards" thing, you'd better start looking for another job.

share|improve this answer
    
+1 Enthusiasm and initiative are your best bet for getting someone's attention. –  chrisaycock Jan 15 '11 at 18:11
4  
+1. If you don't get your team on board, getting management buy-in is going to be worth diddly squat. In my experience older teams get too comfortable this way after so many years and won't change. –  SilverbackNet Jan 15 '11 at 18:44
1  
+1: Find an ally (or several) at all costs. If you can convince them by your own, they won't likely embrace the change when it will be ordered by your boss in your name. –  ereOn Jan 16 '11 at 11:32
    
It is so hard to do it on your own, with no support. –  crosenblum Jan 29 '11 at 13:32
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.