Ask Slashdot: How To Convince a Team To Write Good Code? 366
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?"
Bribery and Punishment (Score:5, Interesting)
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.
QA (Score:4, Interesting)
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.
My wife works in QA, and simply having a QA team is not adequate. Yes, it is one more check (or balance), but it's also redundancy that can quickly overwhelm the primary focus of your coding team.
You need strong leaders in your coding group. If you have strong coders, and they're not strong leaders, think about structuring the work in a way that forces the code into spec. Find ways to develop those leadership attributes, and train the other coders to conform. The nice thing about working with coders is that a structured training program (training, as in behaviouralism) will work - routines, structure and cause/effect (or compulsion loops) are much easier to implement with an emotionally detached, logical group of individuals. You can actually discuss the "training" routine (but don't label it as such) and expect a level of rational resistance to change. Rationality can can be worked with, and in my experience, you don't get people who are much more rational than coders.
It doesn't have to be a permanent arrangement, and it doesn't have to involve raises. It does have to give your team an opportunity to make the transition to a new way of coding without feeling threatened. Think of it as a clean break from a bad relationship. You can't stay friends, you need a complete change of scenery.
Re:Hi, I'm In QA (Score:4, Interesting)
yfnqat,
Everything you wrote is correct and well taken. However, all the things you bring up are not nearly sufficient, and I would argue they are not even the most important. As an analogy, during the '60s, '70s and '80s Detroit automakers developed a reputation for shoddy workmanship. But they did spend a lot on quality control - tons of workers were assigned the job of "reworking" botched vehicles that came off the assembly line. And their dealers learned to do their own fix up work before moving vehicles onto the showroom floor. During the '80s, after the Japanese and Germans started kicking Detroit's butt, a slew of quality consultants came along with essentially the same recommendations:
1. Mistakes have to be caught EARLY in the process, when they can be corrected in a cost-effective manner, not LATE
2. Vehicle design and manufacturing have to be better engineered to reduce the incidence of errors introduced during assembly
In other words, testing is important, but good architecture is much more important. Without good architecture you are doomed to running a treadmill to keep the bugs out as the code is churned for feature development and maintenance.
Re:Sooo.. (Score:5, Interesting)
What companies do you know that produce good, high-quality code? I was depressed to find I couldn't think of many. Maybe Sun before they disappeared, and NeXT, before they disappeared, and SGI.
Re:Sooo.. (Score:5, Interesting)
Google's code that they have released seems pretty decent.
I don't know which code you were looking at, you are probably right. But I can tell you, I've spent a lot of time in the Android codebase, and that thing is giant mess. Everywhere you look there are bugs. You can report them and they don't get fixed. There is undocumented behavior. More than once I've wanted to throw my monitor out the window in a rage after working on Google code. I hate their stuff.
Re:From today's TheDailyWTF (Score:4, Interesting)
Start with teaching the employees the importance of writing good code.
Also teach them how to refactor code in the IDE they use to avoid gigantic monolitic methods/functions/classes.
Then provide them with the tools. In addition to compile at the highest warning level and using the built-in support in the IDEs they should look at Stylecop [codeplex.com] for C# (even though it's more about style than finding potential bugs), Splint [splint.org] for C, FindBugs [sourceforge.net] for Java.
People that are willing to take in and understand the importance of writing good code will end up being better.
And don't forget that people are competitive to some degree - so if you find a way to measure the quality of the code produced it's fine, and let it come with a small advantage. A movie ticket, a box of chocolate or something similar.