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.
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."
(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.
Your comment assumes that the person who criticises bad code is always a factory factory factory guy but fails to take into account that there IS such a thing as good code and bad code. The OP has outlined the reasons for why the code is bad - such as buggy releases, lack of test coverage etc. That indicates that the code or process is bad, somewhere.
Over-engineering is a problem yes, but just as commonly, under-engineering/non-engineering is an equally big problem. Both lead to bad code.
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.