How To Get Developers To Document Code 545
snydeq writes "Poorly documented code? Chances are the problem lies not in your programmers, but in your process, writes Fatal Exception's Neil McAllister. 'Unfortunately, too few developers seem to do a good job of documenting their code. Encouraging them to start can be a difficult challenge — but not an impossible one,' McAllister writes, adding that to establish a culture of documentation managers should favor the carrot before the stick. 'Like most people, programmers respond better to incentives than to mandates. Simple praise can go a long way, but managers may find other ways to reward developers. Are your developers occasionally on-call for weekend support duties or late-night update deployments? Consider giving them a break if they volunteer to pick up some extra documentation burden. Of course, financial incentives work, too.'"
How to poke a dead body (Score:2, Insightful)
Mandate works best (Score:2, Insightful)
code documents itself (Score:3, Insightful)
Crud loads of javadoc/msdn like documents aren't as effective as readable code and a few real world examples.
Management issue (Score:3, Insightful)
Management says "do X" as fast as you can. Programmer does X and report back. Documentation, like proper testing or elegant design, takes time and thus cost money. It often saves cost over the long term but if the management doesn't care why should the programmer ?
Documentation good, comments bad (Score:4, Insightful)
If what you need documenting is at the level of comments within a file your problem is not that your programmers aren't writing comments it's that they are not sriting good software. If meaningful class, method and variable names and sensible expression constructs are used there is no benefit to be had from comments.
I'll make an exception for comments to explain why a given piece of code is not actually batshit insane but required to work with a third-party library you have to use.
Producing documentation that spans classes and discusses how things are designed to work at run-time is, however, part of the job.
Re:Don't Accept (Score:5, Insightful)
You also need a culture that encourages documentation as well. I've met plenty of developers who are thoroughly convinced that the code is the only documentation that anyone would ever need. Here's the problem with that thinking:
void frob_the_splutnik(int a, int b) {
s = get_splutnik()
s.frob(a, b)
}
That's definitely concise, and perfectly clear, but only if you already know what a splutnik is or why you'd want to frob it, and what a and b are supposed to signify. If you're a developer unfamiliar with this code base though, you have no clue what this means, not because you're dumb but because you've never encountered any of the concepts that the original coder had in mind.
Anatomy of a documented method (Score:4, Insightful)
// WHY
int WHAT(...) {
return HOW();
}
Re:Documentation good, comments bad (Score:5, Insightful)
If what you need documenting is at the level of comments within a file your problem is not that your programmers aren't writing comments it's that they are not sriting good software. If meaningful class, method and variable names and sensible expression constructs are used there is no benefit to be had from comments.
They should be all forced to pass HtDP [htdp.org] with all exercises done properly and I bet a lot of them would actually start writing quality code (both quality as in "less bugs" and quality as in "readable"). I love the Amazon comment where a CS PhD admits that reading the book actually taught him to write code properly.
(I have pretty much the same experience, having been subjected years ago to a typical "learn-the-syntax-of-Pascal-and-a-dozen-sorting-algorithms"-style first year of CS at my uni. But they never got around to teaching us how make your brain come up with code like the one in those nice textbook examples in the first place, what are the recurring code patterns (*not* design patterns, mind you). They have never ever once explained how to systematically go (for any problem in general) from a problem formulated in words to a working, readable code. Much like what Dijkstra about the contemporary math education - people memorizing proofs but having no idea how to "do math" in the first place, and teachers hand-waving every objection with saying that studens must "grow some intuition", but never explaining the processes involved explicitly. I believe I eventually got to the point where I started seeing the patterns, but explicitly formulated knowledge could have shortened the process by *years*. Go read the book, do the chores, see for yourself.)
Re:How to poke a dead body (Score:0, Insightful)
It is their job.
If they don't do it, fire them.
If you can't fire them for some reason, give them crap reviews and crap tasks.
Carrot & stick.
I've run multiple dev teams. The stick was doing the builds for all the platforms that we supported ... like 10 of them. It took 4+ hrs. I had a histogram posted outside my office with the names of all the devs and usually the person who did the fewest builds got to do the next one. Simple. When someone screwed up in any way, they got to do builds for a week without any credit. Breaking the build on any platform meant you had to do the build for 2 weeks no credit. Breaking the build was terrible since it impacted 20 other people.
Comments for comment verbosity is worthless. Comments need to say more than what the code already says. I prefer function/method comments more. Explain what the function does for the program and user, not "this is a FFT function" - duh. Say what the input ranges need to be, how exceptions are thrown, if function pointers are used to call it (not easily found in code), etc. Things that are not obvious.
Oh, and no function should be longer than about 20 lines. If you can't see the entire function inside a single window, it is too complex and needs to be simplified.
If you think your code is beautiful and it has been a month, you are confused. All non-trivial code is crap and could be improved in some way. Therefore, the goal needs to be to make all your code appear to be trivial.
Re:code documents itself (Score:5, Insightful)
In my experience, self-documenting code generally isn't.
Proper documentation never explains what you're doing - that's what the code is for. Documentation explains why you did the things you did, which is difficult to express in self-documenting code.
Re:How to poke a dead body (Score:5, Insightful)
Indeed. The rise of "metrics for job performance" has caused a lot of pain for many sectors of IT.
Judging your programmers by "lines of code written"? Great. They'll write a solution with as many redundant lines of code as possible. They won't comment, because commenting doesn't count. Bugfixes will generally involve patch code that means more lines, rather than cleaning up the code itself.
Judging your IT support by "number of tickets cleared"? Great, you get just what people expect out of those @##$@#$ crapass "phone lines" that bank out of India or Malaysia; they'll do anything to get you off the phone as fast as possible and mark your issue "resolved", whether it is or not. Your in-house guys will have to triage: do we handle 5 "my flash isn't working and I can't watch youtube on company time" issues, or do we handle the issue for one person that's going to take ALL MORNING to resolve but since it's only one ticket, will red-flag us as "not getting enough done" according to The Almighty Metrics.
The Retardicans have started to try to put this into play in the education field, too - teachers' pay will now be dependent on the grades the kids get and their performance on certain tests. You can - as my mother has - put in 70 hour workweeks, staying after every day to tutor kids who have problems, seeking out specialists to help the couple of kids who actually may wind up diagnosed with a learning disability (example: one in particular can write at an 8th-grade level but can't seem to wrap his head around long division after 6 months of trying), trying to figure out what's with the others only to find out come P/T conference night that they aren't learning because they've internalized their parents' opinion of school as glorified daycare and therefore just don't want to pay attention - but the parents DEMAND that they be passed on to the next grade because it'll hurt Little Dumbass McAsswipe Junior's "self esteem" to be held back a grade. You can do all that and it WON'T MATTER, because the kids with learning disabilities won't be diagnosed for another 4 years, and there are enough Dumbass McAsswipe Juniors in the class to pull "the metric" down.
Re:code documents itself (Score:3, Insightful)
I prefer the theory that well developed code is it's own documentation.
I'm a Very strong believer in self documenting code, I simply don't allow my team to create objects, variables, functions, etc that don't tell you what they do.
I'm also a strong believer in adding comments to code. Good, self documenting, code should tell you what it is doing without comments, but often the reason Why it needs to do things are is lost or cannot be conveyed in the code.
tl;dr:
Well written code tells you what it does.
Well documented code tells you why it does what it does.
Re:How to poke a dead body (Score:5, Insightful)
Another issue the article touches (and I really shouldn't have to say this because of course you have already thoroughly read the entire article. Twice) is that there's the question of when to start documenting, because software and APIs are often subject to change all the time, not in the least because managers keep asking for new or different features.
Personally, I often enjoy writing technical documentation. If I've written good portions of an API or framework that I'm particularly fond of, because it's all done oh-so-clever, you know, I enjoy committing the inner workings to paper to explain to my colleagues how it works and how it's supposed to be used. Unfortunately, like I said before, there often isn't any time to write good documentation and that's a real shame.
Re:Documentation good, comments bad (Score:5, Insightful)
If meaningful class, method and variable names and sensible expression constructs are used there is no benefit to be had from comments.
This is a naive viewpoint that gets repeated over and over, most likely from people who've never actually implemented or maintained anything more complicated than "hello, world". As a developer I strive to write the simplest possible code (but no simpler!) to solve a problem, but often that code is complex enough or is based on some non-obvious assumptions (device drivers, anyone?) that I can't even remember later exactly why something was done the way it was. Sure, if you write code for relatively simple problems that don't have to interact with other complicated pieces (like the OS or any libraries), you might get away with little or no documentation within the code, but that's not the world I live in.
I do agree with others that external documentation is just as if not more important than internal comments. And while I'm very good with internal comments, I have to sheepishly admit I pretty much suck at doing the arguably more useful external documentation. Perhaps I haven't been adequately incentivised to do that, but then in most environments I've worked in, I get poked fun at for the level of comments I put in my code, not because they are excessive or unnecessary, but because most other code has almost no comments at all, so my code tends to stick out more than it should.
I disagree (Score:5, Insightful)
As someone who's started a new position and using classes with No comments, I can say I've wasted a good deal of time trying to figure out what certain public methods and certain classes do. They've used good naming conventions, but even so there is some subtly about what is done that could have used some explaining, plus looking through 1000s of lines of code before using a method isn't time effective. Its would be far easier for me to read through method header with inputs/outputs than to slog through code trying to figure out if this is the method I want. I don't want every line commented (I've seen that some placws), just the jist .
I came from an internal api writing group, and those using our code would just ask us questions if they couldn't figure stuff out, and we rsther they didn't so we documented ..
Examples or some test code I agree are super useful.
Re:Fire them if they don't (Score:4, Insightful)
I hope to $deity you're not a manager. Your morale must be terrible if you do.
I have to echo other commenters: If you want well documented code, you need to allow sufficient time for said documentation to be written. Failure to do so isn't a failure in programming, it's a failure by management to build realistic timelines based on feedback from programmers.
If your programmers are constantly telling you they need more time, on project after project after project, and it's ALL of them, not just a few complainers, then you need to look in the mirror to find the source of the problem. Go to sales/marketing, read them the riot act about promising impossible deadlines, and get THEM fired if they continue to promise unicorns on a wombat budget.
Re:Mandate works best (Score:5, Insightful)
Re:What?! Give them more money? (Score:5, Insightful)
Your entire premise rests on a few bad assumptions, however:
#1 - that the PHB will know what the fuck he is doing and adequately schedule enough time to document the code.
#2 - that the marketing fucktards will know what the fuck THEY are doing and not overpromise or promise delivery schedules so tight that the PHB has time to allocate to documentation in the first place.
#3 - that the company bosses are not "doing more with less" and overworking their employees to start with, relying on a down economy to fuck the working class by making everyone too scared to quit (for fear of not finding another job and being unable to support their families or being tied down by the risk of losing medical coverage) do 3-4 persons' jobs.
Now let me tell you how the "real world", the world created by the Retardicans for the last 15 years works:
- Employees ARE, as a general rule, overworked. The upper class HAVE, as a general rule, been playing the "do more with less" card so often that employees are doing the work that 5 years ago was done by 3 people.
- Employees ARE, as a general rule, fucked by the system. Need to find another job? Better hope it covers healthcare. The upper class don't have to give a crap about health care, the poor will never get out of people poor because if they ever did medical bills will put them right back, and the middle class lives in daily fear of losing health care coverage and being put into the poorhouse by medical bills - for themselves, spouses, parents, kids, anyone in the family.
- Managers are fucking assholes whose job it is not to work with the employees, not to ensure that enough time is allocated for things that need doing, but to be slave drivers. We just had a slashdot article covering the latest problem of people feeling too scared to take vacation because of how managers behave about it.
What we need are far stronger worker protections. The Retardicans have been screaming about "obamacare obamacare obamacare" like it's some kind of bogeyman, but actually, single-payer and guaranteed healthcare coverage are GREAT for the working class, because it's removing the iron ball of "healthcare tied to your asshole fucking boss" from their legs and will let more people actually look for better jobs, or even start their own businesses without the fear of one accident or one unexpected illness ruining their entire lives.
Re:How to poke a dead body (Score:5, Insightful)
I totally agree.
You want to know how to make developers document? Give them time to do it. Do not give them another project until the one they've just deployed is documented. Factor in time for documentation when quoting for the time taken to complete a project, and don't treat documentation time as "pad" time that can be consumed by the project when it overruns its overly-optimistic deadline.
Treat documentation as as valuable as code, and it will get done.
Re:How to poke a dead body (Score:5, Insightful)
It is their job. If they don't do it, fire them. If you can't fire them for some reason, give them crap reviews and crap tasks.
I envy you that you work somewhere where there is an excess of perfect people that you can do this. In my experience there are some really clever people out there who have some personality flaws, and there are lots of people who stick to the rules and are quite average. Personally I'd rather try and work with flawed brilliant people and accept undocumented but efficient, quick, timely code than get a monkey who follows the rules and produces acceptable code. You may not choose that trade off and that's fine we will probably never agree there... ;-)
Now if you're telling me you can get someone who does everything brilliantly then great, but lots of great engineers are divas so whilst you can try and lead them, to give someone a poor review (when they saved your behind at the last customer demo) because that code they cooked up lacks documentation then I'm once again wondering how on earth I ended up with such an awesome job.
FWIW I used to have a manager whose approach to people who he thought produced unmanageable/undocumented code was to stick them into a code maintenance/system integration role. It was interesting how quickly you then started complaining about other people's code and documenting both theirs and yours
Oh, and no function should be longer than about 20 lines.
Where's my funny mod points when I need them?
All non-trivial code is crap and could be improved in some way
I would say all code is crap and could be improved, the problem is where and for what purpose? Code with too much abstraction is crap, so is code with 1 line per function, so is code with too many things happening on one line, so is code that is too tied to the particular hardware, so is code that ignores what the toolkit libraries can do, so is code that is written in the wrong language for the problem you are solving, so is code that is a complete re-write, so is code that wasn't profiled properly. etc
Any blanket rule you can make has exceptions and while I am all for coding standards and code reviews rules are there to make you think before you break them, nothing more.
I document for myself (Score:4, Insightful)
Six months from now, long after I've moved on to something completely different, am I going to remember a function's return values? The inner workings of a particularly complex algorithm? Or the reasoning while a special case has to be handled differently?
If it's not going to be obvious to myself later on, it's worth adding a concise comment to explain.
Re:How to poke a dead body (Score:4, Insightful)
Most of the time the problem doesn't lie with the developer. The developer who actively refuses to document is rare. In my experience, the real problem lies in managers not taking documentation seriously. It is caused by developers being under the stress of deadlines with a manager that really needs this piece of software to be finished yesterday. Managers just don't schedule in any time for documentation.
Roll it up the chain, the Manager's manager doesn't value documentation, they value product, as does the customer. Internal documentation is something with a payoff next quarter, or more often next year. When is the last time you heard of an American business strategy that involved taking more time to do something now so that you could take less time to do something next year?
I never understood this... (Score:4, Insightful)
I always document my code. It saves time later. Six months down the road I'm not asking myself "why the hell did I do that?" It's for my own protection. I've had programmers tell me that they don't document their code because it's obvious what the code does, and sometimes that's true. But I think at least some of the resistance later to add features or fix bugs has to do with not wanting to struggle to remember what the code does. And -- this is just me, but -- you probably don't want to have a reputation for being uncooperative and not a team player in a down economy.
In a very early job, a guy with more credentials than I wrote a program we all used in a language I didn't know. There was a longstanding bug which he refused to fix [1], and he kept the source in a protected directory. So one night we broke into his account, I scooped the completely undocumented code, figured out the problem (had to change *one* (1) character!) and distributed the new binary. It took him awhile to figure out what happened. Boy was he pissed.
[1] Whether this was a dominance game or he really did not want to try to figure out the code he had written months earlier was a point lost in history.
Re:code documents itself (Score:4, Insightful)
Indeed, even if your code is complete clear on what it is doing, you should at least put in a comment on *why* it is doing what it is doing.
Obviously, I used algorithm A, but why did I pick it over algorithm B. Is it because B isn't faster in this particular case or because A is less memory intensive, etc.
Re:How to poke a dead body (Score:5, Insightful)
Metrics aren't bad in themselves, but bad metrics are terrible. Lines of code written is a really bad metric.
I've seen the ticket one happen too many times. Someone will call because n people are having a problem, and ask if the hell desk person wants the info on the other people so they can get fixed, too. Nope. Have them call and open tickets. More tickets with simple, known solutions == more tickets closed quickly.
And yeah, the same is true of teachers. Teachers *should* be judged on their effectiveness, but the way we do it is often nonsense. Don't ask me to come up with the method, the one thing I DO know is that someone with no experience in the field (me) should not be the one divining metrics to measure them. That said, we've all been through school, and some of us have put kids through school. You know some teachers are better than others, and some are really bad. We do want to find ways to encourage all of them to be better and to get the worst to go do something else. There are also fit issues between teachers and children. The teacher you found to be great for your kid might be average or bad for mine.
Re:I like to use a big stick (Score:3, Insightful)
Or they will show you why code comments are a bad idea.
Code comments are usually unmaintainable artifacts; misleading at best.
The best kind of documentation is architectural description of the solution. Everything else is just rubbish. I want to see code comments WHEN they are needed - and the fewer the better. If you write your code in such a manner that it needs documentation, then you might have done a bad job ad writing code.
Example of moments when you NEED to document code: module boundaries, interfaces and implementation hints for when the code needs extension. But by no means should one document EVERY call; but the most important ones. Code samples would help.
Just some programmer's opinion
Re:How to poke a dead body (Score:3, Insightful)
If 20 lines of codes is your boundary of complexity, then programming is not for you. Breaking code into screen sized 'called once' sections adds unnecessary complexity, especially if you validate your inputs(as all good programmers should).
Some things are just inheritently complex and the most efficient implementation might be rather abstract and not obvious at first. If you can't understand it at a first pass, the problem isn't necessarily the code.
Re:How to poke a dead body (Score:4, Insightful)
Unruly behavior like refusing to follow coding standards can be a sign of a problem employee that you have to let go, but it can also be a sign that all of your developers perceive your policies to be detrimental to both them and the business, and this person is the only employee you've got that cares more about the company and his craft than about his immediate bosses' sensibilities. That sort of courage could easily derive from the fact that perhaps this person is the only person who is in demand enough that he could easily find a job elsewhere. Managing by badgering, lashing and threats of firerings is a great way to lose the respect of everyone working for you. That's when suddenly productivity drops and bugs go up for no apparent reason.
If you are a leader, and if people thought that a policy was god-awful, and then suddenly they all stop talking about it ever to you, that probably means that they have given up on your organization due to your leadership, and now they are just going in from 9-5, doing whatever you say to keep you happy, while not showing any initiative to bend your policies in the interest of the business - they are probably also looking for a different job at the same time.
An employee who does just exactly what you say is the worst possible kind of disaster waiting to happen. You absolutely need your employees to question you. "oh, you need me to quickly finish this piece of code because minor customer X wants it now? Well, I happen to know that that same routine will have lots of bugs if not done carefully, and we are going to use it also to give to our major customer Y, to whose interests it is vital that this code work perfectly, but I won't question you by mentioning that and instead give you what you asked for." It's called malicious compliance. If you insist that employees ignore the good of the business and follow your orders to the letters instead, then watch out, you may eventually break some of them to give you what you ask for, and you won't like it.