Slashdot Mirror
Ask Slashdot: How To Convince a Team To Write Good Code?
An anonymous reader writes "I am part of engineering team that maintains a very important component in our company. Our code quality and general engineering quality focus has been very weak: we have frequent buggy releases, our latencies are shooting up, our test coverage is nearly non-existent, and it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity. A group of 2-3 of us want to change that, and we know what needs to change technically — the better code review and release processes, better build tools, etc. But despite that, the quality of our code and design continues to suffer, and poor code continues to get released in the name of keeping the scheduled release date (product guys don't like to wait). We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace. How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?"
Do you work for Blizzard?
1. Higher Pay
2. Good Management
3. Beatings
Pick any two.
What you have just described is what happens when Management does not see value in what you do.
To them, you are just an interchangeable cog. Like, the brand of air conditioner in the office. Or the janitor. It has no bearing on their success and they don't really care what you think about anything.
The way they see it, if you don't do your job, they'll just replace you with something else.
Your best bet is to leave. And do as little work as possible in the meantime.
It is very clear that your company is a typical feature and marketing driven morass. What happens is you flog yourselfs until something goes horribly wrong, a bunch of people are fired. Then there is a new director of technology, who gets a ground up rewrite approved to enter some new space, and the cycle of accretion and feature creep starts all over again. So advice? Polish your resume or make good friends with who ever will run the purge when it happens.
Fugue for Aaron Swartz
Of how much time and productivity is being wasted on inadequate practices and how much you'll improve your product, discover bugs faster and generally innovate with your improvements. Worst case, you'll need to do a shame trip on a few egregious offenders (pick their work and try to exclude names) and show how you'd do things differently.
The benefit from your improvements must be obvious, immediate and beyond reproach.
Fair warning: You cannot change the mind of management if they're more worried about maintaining the status quo. A very likely issue, if it's been this long with no improvements. All of the above will only work if your 2-3 people have any position of authority within the company. In my experience, the old-dogs don't want to or can't change, in which case you'll be on your own.
Of course, you will also earn the ire of those around you if it's that type of atmosphere. People fear change when they're not the ones doing the changing.
If computers were people, I'd be a misanthrope.
Hopefully you have a QA team...if your project is large enough and you do not have a QA team, consider proposing the concept to management. Proper controls and planning on unit test, functional test, system test, solutions test, things like that are all really required to help keep large, multi-developer projects in check, especially in this day and age of migrant coders, on-and-off contractors, and out-sourced-then-imported coding jobs.
Having strict thresholds as to allowable defects per release, enforced feature regression guidelines, expected/projected pass/fail rates per test case, etc. can all be very useful if used PROPERLY to improve code quality. I highlight properly because some managers misuse metrics as the final yardstick of worth of employees, when at the end of the day it is much more complex than developer a fixed X defects or tester Y passed Z test cases this week. Implement proper code reviews, have a consistent and formal process for testing, finding defects, defect resolution, targeted releases. Have your QA devise up with your strategies, test plans, test cases, have them cross-reviewed, and start testing cycles based on release cycles.
If you aren't doing any of the above, imposing some of what I mentioned is sure to have a positive impact on subsequent quality. If your code sucks, it will reflect your team, your company, your management, and your bottom line in the long haul (IMHO, YMMV, IANAManager).
Signed,
Your Friendly Neighborhood QA Tester
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
People do amazing things when they feel like the thing they're creating is an extension of themselves. Far more than any engineering process or philosophy I've seen, the best work I've seen in my career is from people who identify strongly with their work.
"Why can't everyone just be straight with me?"
"Because we live in a bendy world, dear."
Get your team to write "Good Code", eh?
Does your team write bad code? Do they think that their code is bad?
Why do you think that your team writes bad code?
I'll bet a nickle that the problem isn't your team. I'll bet that you're the type to write a factory factory factory under the banner of "flexibility" and not understand why everyone groans at your "superior" code.
Required reading for internet skeptics
(1) Code reviews. At first, just get 'em to grab a passer by to look at their code prior to check-in. If the PB cannot understand what they've done, they haven't finished the job. Later on you can upgrade to more stringent reviews, but the first thing is to get *some* reviews happening *at all*.
(2) Comments and (some) documentation. You need to lead by example. This stuff isn't optional.
(3) Unit testing. If your code base is a pig, you'll need to start somewhere and begin teasing out the "bits that think" (easier to UT) from the "bits that talk to things" (these are harder to UT and you can get away with integration testing here until you're in better shape). Unit testing is a skill anyone can learn. Sack 'em if they refuse to do it!
(4) Simplify your processes and your architecture where possible. Avoid trendy bandwagons. If the obvious thing works and is maintainable, then that is probably the best way to go.
Ok.. those are strong words in the subject, but inducing a culture change quickly is something you can incentivize. I'm not sure of your particular situation, but here's two ideas:
1. Bribe them. Companies usually call this merit based bonuses. Break the goals of the team(s) into individual goals. If a particular module is due to be rewritten for the next release, then pay a bonus if it gets done correctly and on time. If it's not done correctly, don't pay the bonus. If it's not on time, don't pay the bonus. With regards to it being "correct", that falls into the next item..
2. Punishment. If the code sucks, don't commit it. Force the programmer to rewrite it. That even might mean rearchitect it if there was architecture involved. Programmers hate repetition. They will very quickly learn that if they are forced to do something over that they can do it better the first time. If they find themselves working late hours to meet a deadline, perhaps because a bonus is riding on it, they'll get better.
Most important, make sure your deadlines and features are realistic. Are you sure they are? Are people being sloppy because they feel too pressured? Shipping a buggy feature isn't a feature.
----- obSig
Yep. You're going to have to make a business case for what you want to do and show management what it will save in $$$ or change will come with much more pain, if at all. You are going to have to argue sensibly and make sense to them in a language that they understand. This should be at most two to three pages covering the nature of the problem, how it can be solved and a budget and/or cost comparison. You want to be coherent and concise without getting into too much detail and three pages is about as much as you can ask a high-level manager to read. You are talking about major process change within the structure of the company. You might think it's trivial (or not), but understanding as much as you can about what effect this has across the board (not just in the software you're writing) will help you make a better case for this kind of change. You will also need to appeal to the bottom line.
If as the submitter claims "new people take a month to get up to speed" then either their project is trivial or they are doing something right.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
One man's clean code is another man's over-engineered rubbish. The industry is not as united on the definition of "good" code as one might expect it should be, and in my (lengthy) experience with developers of different temperaments, there is great variance in how code is received and evaluated.
The standard of judgement that gets applied to code is not objective, and never will be. It cannot be, as coding includes art as well as science.
Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
Find a job where the programmers evaluate code similarly to how you do, and you will be much better off.
As an aside, I have worked with developers on both ends of the spectrum, and found that both extremes are equally bad in different ways:
1) Hastily-written code makes the trade show date and wins business, but can really ruin a company's reputation when the app doesn't scale and the bugs drive clients' costs through the roof. Contrary to the beliefs of those who write such code as their standard MO, constantly delivering maximum value in minimum time is NOT sustainable in the long run.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
Successful businesses will find a happy medium between these two extremes, much to the chagrin of developers who earnestly believe one extreme is better than the other.
With out a doubt you need to be able to measure what works and what doesn't but the moment some first turns to any kind of standard or the nightmare word "metrics" you have already failed. Too many companies go through all the fads and all the silver bullets. They have scrum masters, and black belts in Six Sigma (I am not making up the black belt part) but the fundamental problems are not fixed. Often the first place to start is with communications. Who does communicate and who is supposed to communicate. It is great if the sales people can bounce stuff off the programmers in the lunch room and even better if the programmers meet the clients but once the sales people are able to direct a project the project will instantly start chasing rainbows.
The second place to look is the why? Software is made for two reasons, to make money or to avoid losing money. This allows you to boil down any "solution" to the money. So if the argument gets into religious territory such as language choice, OS choice, documentation, or even commenting style you can then ask, how does this either make us money or prevent us from losing money? So someone might say, such and such a documentation system is better when you can then ask, lets look at the cost or value of us having no documentation at all vs perfect documentation. After breaking it down you might find it is a huge cost one way or another and your decision is made for you. This prevents programmers from continuing to try and impress their long past CS professor and his insatiable demands for Hungarian notation. But as a pro-documentation example if you are routinely cycling in new programmers into a project great documentation can pay for itself in spades; but first you must calculate the cost of bringing a programmer into a project sans documentation and bathed in documentation. Did that documentation save more than it cost to produce; you might argue that a good documentation is low cost but again compare that low cost to the cost of not having it at all or having less.
So better engineered high quality code feels like a great idea but make sure that the value of increasing quality does not have a disastrous business result. A simple example would be if your company's business is famous for being first to market with each new feature. People might grumble about how it crashes quite a bit but that since they make $500,000 a day using each feature having it a week earlier than the rock solid competition is very valuable. So if you slow the process of delivery down by 8 days and make the software perfect you will be out of business in no time. This is all a bit extreme but I suspect your core business is not making software but doing something else that the software supports. So it is quite possible that your company is mildly irritated by the bugs but that they exploit the features quickly.
Personally I have found that unit testing on larger projects ends up speeding up deliveries but on smaller projects definitely delays delivery.
One bit of horrible experience that I have picked up over the years is that some great systems were built on truly terrible code and truly terrible architectures. The disasters were also legendary but more often than not the cost of the disasters still justified the speed to market of the terrible system. Some systems were then recoded after disasters and made great but often at the cost of many release cycles resulting in a business disaster far greater than the disasters prompting the recode. Often the best solution was to make the code base slightly less terrible and press on at full speed. I have seen this terrible code and it is just solid WTF but when you look at the piles of money generated you just get angry that your own "perfect" code didn't make you rich. But as a counter point I have seen systems so terrible that the disaster took out the company; but even there just a slightly less terrible system would have saved the company. (The example I am thinking of had no backups so they lost everything, POS, invento
Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
1 Do you use source control?
2 Can you make a build in one step?
3 Do you make daily builds?
4 Do you have a bug database?
5 Do you fix bugs before writing new code?
6 Do you have an up-to-date schedule?
7 Do you have a spec?
8 Do programmers have quiet working conditions?
9 Do you use the best tools money can buy?
10 Do you have testers?
11 Do new candidates write code during their interview?
12 Do you do hallway usability testing?
Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:
And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".
Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.
Browse around the site and read some of the other articles as well. There is a lot of good advice there.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
That is an excellent point. But I would counter that the aim is not reduce time of delivery, but to control risk (and ergo, cost). As a business, I would prefer to know that something will consistently take me, say, 4 weeks, of testing and delivery with fewer bucks, than knowing I could "deliver" in half the time, but with a "hidden", hard-to-quantify, highly variable cost of defects, maintainance or extensions.
With the former case, I can consistently ballpark the cost and ROI. With the later, it's like driving while blind.