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?"
Stop pissing in the wind (Score:5, Insightful)
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.
You are doomed (Score:5, Insightful)
This does not bode well. (Score:3, Insightful)
Your inability to proof-read the text of your submission does not give me hope for your team. ("I am part of engineering team...", "...non-existant...", "...we would can eliminate...")
Create a presentation (Score:5, Insightful)
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.
Re:You are doomed (Score:0, Insightful)
it was a failure the moment i saw the following line: "I am part of engineering team"
no further discussion necessary
Hi, I'm In QA (Score:5, Insightful)
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
GIve them a sense of ownership (Score:5, Insightful)
Just like snipe hunting (Score:4, Insightful)
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.
Re:Just like snipe hunting (Score:5, Insightful)
Over-engineering is a problem yes, but just as commonly, under-engineering/non-engineering is an equally big problem. Both lead to bad code.
Dollars & Sense (Score:5, Insightful)
Re:From today's TheDailyWTF (Score:5, Insightful)
Re:Stop pissing in the wind (Score:5, Insightful)
I view management as cogs too, they are fairly interchangeable, and on their own worthless. Put them all together in a bag and you get a percussion instrument. Percussion instruments are essential to music, and you can bang on them with sticks or mallets.
Re:Stop pissing in the wind (Score:3, Insightful)
Other than doing as little as possible, I wholeheartedly agree.
You should work hard while you're there though, if for no other reason than because doing things the right way in the wrong environment is really, really hard and you'll learn a lot. Properly made code doesn't interface well with awful code, but it's a task you'll have to do at least occasionally for as long as you're a developer. Being good at that is an invaluable skill.
It's also nice to not feel awful about what you left behind, if you're the kind saddled with a conscience. Do it without complaining uselessly (you also shouldn't just hoof out the door without at lest trying to change things if you like where you're at), and you might even be remembered well, which is a really good thing when the economy shits itself as it occasionally does, or if somebody you worked with and respect later has an opportunity to recommend you for a better position.
Money, and recognition !! (Score:4, Insightful)
As one who has plied this trade for decades, I'll tell you that programmers are human beings, just like everyone else.
We urge for recognition, and we need money.
You just do not tell us to do what you want us to do without recognizing the hard work we have put into debugging the products.
And you will not go anywhere if you do not pay us.
Re:From today's TheDailyWTF (Score:5, Insightful)
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.
Culture (Score:5, Insightful)
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
Start with management buy-in, and start small (Score:4, Insightful)
It sounds to me like this is a group of 2-3 developers who want to improve processes, without (currently) support from the business, which just wants to keep shipping on time. If you can't get management support, you're going to have a hard time, so that's the place to start.
If your management doesn't understand the concept of Technical Debt [wikipedia.org] and how it's costing the company time, money and reducing your agility and competitiveness, that's where you need to start. How to go about educating them is something that you're going to have to figure out for yourself, since you know the people and the context, but I'll give you a warning: people don't like to be told they don't know their business. If you try to approach it like that, you're very unlikely to be successful. And, frankly, unless the group trying to initiate the change is already among the top performers, and has a track record of successfully delivering, you're unlikely to be successful no matter how you go about it. So you first need to get the guys the management perceives as being their top contributors on board.
Still, if you can get the conversation started in the right way, technical debt is a concept that business people can easily grasp, because it so closely parallels the notion of financial debt. For that matter, you should make sure you understand it thoroughly as well, including the fact that it often makes perfect sense to take on technical debt in exchange for a business advantage which is likely to have sufficiently-large rewards. Never forget that the purpose of the code is to generate revenues, not to appeal to your sense of aesthetic purity.
But, technical debt slows progress and massively increases the financial impact of bugs. The interest will be paid -- there's no avoiding it or deferring it -- and as the debt grows it becomes a burden which sucks up all resources. If you can get your management to understand and agree on that, you've won, as long as you don't screw it up.
To avoid screwing it up, do not embark on a massive development process re-engineering effort. If you do, you'll fail. You'll delay the next release, cost the company large amounts of money and customer goodwill and completely undermine everything you said.
Instead, figure out what one thing you can change which will have the most immediate significant and measurable impact. Do that, show the benefit, then move on to the next incremental improvement. This is hard. It requires you to not only figure out what will help the most, but also how to measure the before and after states, and to ensure that your measurements won't be gamed or encourage counterproductive behavior. Also, spend a lot of time thinking hard about how to make the change in a way that will have the lowest negative impact on productivity -- because anything you change is going to hurt at least a little, in the short term.
Though you need to look at your own situation, my prediction is that the thing that will do you the most immediate good is code reviews. Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify. With a little care, it's easy to document the financial benefits of code reviews. But to make them work, you first need good code review tools -- sitting around a table with printouts wastes everyone's time and rarely accomplishes anything. Spend the time to find a good code review tool that you can integrate into your workflow, set it up, test and validate it and be sure that it's going to work well before you ask people to use it. Note that this is all a lot of work, and unless management is extremely enthusiastic you'll probably have to do a lot of it during evenings and weekends.
Once you have it working for a while go back and pull out a bunch of reviews and take some time to carefully analyze what kinds of bugs were identified and fixed in the review process, and try to estimate what it would have c
Re:Just like snipe hunting (Score:4, Insightful)
GP is part of the problem. For people like him/her, it is not about good code or bad code, it is about 'my way or the highway'.
Calling someone "factory factory factory guy" without any basis is how you get mod points on Slashdot without being correct. For all one knows the submitter might be exact opposite.
Re:Hi, I'm In QA (Score:2, Insightful)
No. Please god NO.
QA is not the Release-Police and shouldn't _ever_ put themselves in the role. QA's role is to tell you that something _is_ a buggy piece of shit, that Devs have been too stressed, that planning didn't go into architecture, and that all the "Crunch" is going to come back and haunt twice over.
QA can have the role of saying that something stinks, but should also be able to tell you _where_ and _what_ and in some cases _how_ it stinks.
However, QA should not be able to say "We won't release this piece of crap" because if QA starts doing that, QA will be opposed to release and Management, thus QA will never be allowed to do a good job. QA will then be the dreaded guys of white tape or code-reverts, and you don't want that either.
What you want is to have a QA team that are your friends. Not the roadblock to release. Even if you're trying to release a steaming pile of pig manure in the shape of IE6.
Re:Sooo.. (Score:3, Insightful)
Consistently or occasionally? From what I've seen, your average company produces one or two great products and a lot of half-assed projects. I call this the Lightroom-Flash spectrum. On the upper bound, you have code that is fairly well written (apart from that case-sensitivity maps bug, ahem...), and on the lower bound, you have... well, Flash.
What distinguishes one from the other? IMO, you can roughly quantify it as: q = 1 / (t_sub_r * b_sub_p), where q is quality, t_sub_r is time since the last ground-up rewrite, and b_sub_p is the bug punt rate—the number of bugs that got punted to the next release because you couldn't fix them.
In the average organization, T_sub_r is a linearly increasing variable based on time, because rewrites never happen. Similarly, because the schedule is fixed, the total number of bugs is proportional to the code size, and the number of coders is also proportional to the code size, the number of bugs punted tends to be proportional to the code size.
Assuming your code size increases roughly linearly based on time (but in sudden jumps at every release), then code quality is roughly O(1/(t^2)). With products that are given adequate care, though, the schedule lengthens or the rate of code expansion tapers off over time, so that Q is probably closer to O(1/(t * log_base_k(t))) for some base k.
Either way, though, it's a race against the clock, because the OS is changing under you and the world is changing around you, so even if you did absolutely nothing, the code quality would fall off at a rate of O(1/t^2), because all of your bugs are punted.
Either way, the only way you'll ever do better than 1/t is if you periodically do major rewrites of big chunks of code. Of course, this introduces a whole new set of bugs, but the code quality will improve because you will have learned (hopefully) from the mistakes of the previous version of the code. And you must do this for pretty much every section of your code on a regular basis or else the old, crufty parts will eventually degrade into a black box that everybody is afraid to touch.
Or you could just do everyone a favor and periodically introduce code that looks like this [thc.org] weaved in and among what you consider crap code in an effort to force people to rewrite it.
Joel on Software sayz (Score:5, Insightful)
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 [joelonsoftware.com]:
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 [joelonsoftware.com]:
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 [joelonsoftware.com] explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I [joelonsoftware.com] says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful [joelonsoftware.com] 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.
lack of ethics (Score:4, Insightful)
As one who has plied this trade for decades, I'll tell you that programmers are human beings, just like everyone else.
We urge for recognition, and we need money.
You just do not tell us to do what you want us to do without recognizing the hard work we have put into debugging the products.
And you will not go anywhere if you do not pay us.
If we need recognition in order to do work of acceptable quality, we have an ethics problem. For people with a sense of professional ethics, recognizition and remuneration are pre-conditions for staying at a company or project. But they are never pre-conditions for doing developing software with a professionally acceptable level of quality. Professionals leave, when the time is right, when they feel unrecognized or underpaid. But they do not deliver shit.
Barring the unavoidable hacks that must happen here and there, software professionals with work ethics do not deliver shit even when unrecognized or underpaid. The greater problem in the software industry is not the lack of recognition (and certainly not the lack of good pay). It is the scarcity of developers with a sense of work ethics.
Re:From today's TheDailyWTF (Score:5, Insightful)
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.
Re:From today's TheDailyWTF (Score:4, Insightful)
> 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.
The better programmers leave their ego at the door. As Neil Peart brilliantly said recently:
Q. I think that a lot of people are surprised to learn that you still take drum lessons. You're seen as this drum master by most everybody.
A. What is a master but a master student?
http://www.rollingstone.com/music/news/q-a-neil-peart-on-rushs-new-lp-and-being-a-bleeding-heart-libertarian-20120612 [rollingstone.com]
If programmers have that much ego, it is probably better that they leave since they have shown that they aren't interested in learning a different perspective. (This can apply to both the young-whipper-snapper or old-crotchy ones equally.)
Every time I was forced to use a new coding style I initially disliked it. But I always was able to put my ego and biases aside and ask myself:
* What are the advantages of this way?
* What are the disadvantages?
Only by understanding BOTH answers can one really grok what works and what doesn't work. The rationale is more important then the rules.
The same thing applies to naming conventions.
Likewise, I've worked on code where there NO getter-setters allowed at all, where you MUST write getter-setters (even trivial ones), and ones where there no trivial getter-setters. The 3 different styles made me appreciate the different trade-offs.
> 1) Hastily-written code makes the trade show date
> 2) Writing very clean code, and then keeping it clean
Yes, completely agree there are 2 extremes:
* Ship it
* Over-Engineer it
> Successful businesses will find a happy medium between these two extremes,
Again I concur 100%. A pragmatic programmer knows when to just "let it go" and when to "rip everything out" -- the code is good enough, and when to re-architect, re-engineer, re-factor, etc. because the original code no longer solves (or handles) a different set of requirements.
It is a tough balancing act but there is one general guiding principle.
If you can achieve the same solution with less code then that is preferred. Less code has less bugs, and less edge conditions.
Smaller code is usually more beautiful then Large code. :-)