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?"
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
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.
Heh, that raises a question. I often complain about other people's code, it's a typical developer hobby. I can name a lot of companies that produce lousy code, but
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."