In software no good deed goes unpunished
(March 30th, 2007)
I had an all-too-familiar conversation with an engineer the other day (we’ll call him Mark). As I was reviewing a bunch of code that the company had written, every time Mark would encounter code written by a particular individual (we’ll call him Bob) Mark would take on a derisive tone and say “oh, that’s more BOB code” implying that the code that Bob wrote was an unfortunate blemish that they had not yet had time to clean up. After about the tenth time I was beginning to get the sense that most of the code we were working on was “Bob” code so I asked Mark what was so bad about Bob’s code. He replied that “there are a ton of bugs in Bob’s code. He worked here for only a couple of years but somehow every time something is broken it’s in Bob’s code. I’d say that at least a fourth of the time I find a bug it’s because of something that Bob got wrong.”
From that conversation I presumed that Bob must have been a pretty prolific bug generator, so when I started reading his code I was a bit surprised at what I found. It was really not that bad at all. It was clear he didn’t take enough time to go back and refactor things, so a lot of it was what I would call “straight-line” code that just solved the immediate problem in the most direct way. This meant a certain degree of redundancy that was more than I would have liked. Still, he never seemed to be engaged in grossly excessive cut and paste coding, and he seemed to be able to refactor things to a degree (none of those horrible value-objects with helper functions everywhere style efforts). Basically, aside from being low on comments, and perhaps a bit ugly in the formatting department I guess I’d say that Bob’s code looked to be above par for what I’ve seen from legacy code at most companies.
I was even more surprised when I looked at the non-Bob code. On the whole, other than having a clean appearance and big (but useless) comment blocks everywhere, it was mostly worse than the code that Bob had written. I found lots of excessively complex classes that needed refactoring and a good number of multi-page functions. I saw evidences of wholesale cut and paste. It wasn’t awful code, but it was definitely worse than the code that Bob had written.
The next day I asked the manager of the team about Bob. He said that “Bob was really great at completing projects. Whatever I gave him would get done right away. Unfortunately, the engineers tell me he took a lot of shortcuts and never commented anything. Personally, I liked him a lot, but he got a better offer and we couldn’t keep him.” By this point I was pretty sure that there was a big perception versus reality gap about Bob. A few minutes with Perl and the cvs info command confirmed it. My superficial analysis revealed that 1) almost half of the code in the company had been created or modified by Bob (as measured by lines), and 2) the code checked in by him had an average cyclomatic complexity (weighted by function size) of 22 compared to 43 for the rest of the code base. Basically, it looked like Bob was writing a lot of code that (superficially at least) was slightly better than the majority of the code written by everyone else.
There are a few possible reasons for the apparent disconnect. It’s possible that the other engineers are right, and that while Bob’s code is superficially better, he regularly engaged in incorrect thinking that screwed it up in less obvious ways. While this is possible, I think there’s a much more likely explanation: since Bob wrote most of the code, he also wrote most of the bugs. He did so much more than everyone else, that it’s all the rest of the team can do just to keep up with the maintenance on that very large code base. If Bob really did write almost half of the code, then being responsible for a third or a fourth of the bugs isn’t a sign that he was lazy. It’s a sign that he was at least as disciplined as everyone else.
All of this confirms a theory I have about some companies. If the culture is broken, the fastest way to make enemies is to do more than everyone around you.
March 30th, 2007 at 4:47 am
Wonderful post, truly. And thanks for mentioning “cyclomatic complexity” — I had never heard of it.
March 30th, 2007 at 12:52 pm
[…] Code Craft » In software no good deed goes unpunished Wonderful post about writing code. memo to self: look up “cyclomatic” (tags: programming writing) […]
March 30th, 2007 at 2:33 pm
That’s one of the most interesting programming anecdotes I’ve ever heard. Good food for thought.
March 30th, 2007 at 3:02 pm
This applies generally, not just to software. I know someone who worked as a municipal gardener. On his first day on the job, eager to make a good impression, he worked as hard as he could. An older man took him to one side after a couple of hours and asked ‘Do you have any idea how many people you are going to get into trouble if you carry on going that fast?’
March 30th, 2007 at 4:16 pm
That’s typical “peer review bias”. Programmers like to “one up” code that’s not theirs.
I had an ex-colleague (thank God she left) who seem to enjoy bitching about every single line of code that’s not hers.
“When I was in xxx, this sort of coding is not tolerated.”
“This is so inelegant. When I was the sole programmer for an ERP system… bla bla bla.”
“Yucks! In Delphi, this is much easier.”
I was this close to resigning, and I attribute 30% of the problem to her alone. I just can’t stand her whining and superiority complex, and got an offer from an expanding IT startup.
Turns out, she was on her way out anyway and senior management asked me to reconsider. I did.
She left and was demoted as soon as she joined the company. You can probably code around problems. But when it comes to attitude it’s not so easy to debug.
March 30th, 2007 at 5:19 pm
That was an amazing post… I really enjoyed reading it. It’s not the usual stuff we’re used to hear about. I’m putting this on my del.icio.us right now!
March 30th, 2007 at 5:45 pm
Jeremy’s law: The greatest cause of bugs is coding.
Prove it as follows: For any programmer whose rate of bug generation k is greater than 0 for some number of lines of code n, the number of bugs generated will be equal to k*n.
The best you can do is try to make the number k and the number n as low as you can.
March 30th, 2007 at 5:53 pm
Great post with useful information.
March 30th, 2007 at 6:00 pm
I unfortunately see myself in the “bitching about other people’s code” dept. But what can I do…. it really is bad, and it’s hard to just swallow it. A lot of the developers make it clear that they have learned just enough about the language and libraries we are using to barely get by. They do things in a much longer and less maintainable way than if they would just read (and understand) a few chapters of some key books. They know nothing about object-oriented programming and are masters of the cut-and-paste, which sometimes makes me do the exact same change in as many as 20 places in the code. I have on several occasions had to go back and fix bugs in my parts of the code that they had introduced. Hard-coded values (without constants) are everywhere. Constant strings are bad enough but there are also lots of hard-coded numeric codes, with not even a comment to explain why this block is executed only if “someCode” is 234, 76, or 2.
It’s true, so what do I do… just shut up about it?
March 30th, 2007 at 6:30 pm
[…] In Software No Good Deed Goes Unpunished All of this confirms a theory I have about some companies. If the culture is broken, the fastest way to make enemies is to do more than everyone around you. […]
March 30th, 2007 at 6:39 pm
Nice article. I’m wondering what you meant by “none of those horrible value-objects with helper functions everywhere style efforts”. Got any examples or more detail about what you mean there?
March 30th, 2007 at 6:43 pm
greg Hall: what I would do is write a bunch of unit tests against their code. Eventually they will break as they’ll have to change a constant. Course you might get blamed for that but hey you tried to show them the way in a non-cofrontational manner.
But really this should be handled by a project manager / dev lead / whatever. But if he / she has let it go on for so far then maybe they just don’t care. Just don’t care why it takes a week to make a simple change.
If you want to get hard core about it try writing a FindBugs detector for all their bad code. So if the carrot of junit tests don’t make them change beat them with tiny red bugs.
March 30th, 2007 at 6:50 pm
Excellent article. Nothing speaks louder than numbers, and it was nice to hear you were able to find a way to validate your intuition about Bob. I’ve starting looking for metrics as a way to build up objective points of analysis on a programmers work. It doesn’t do everything, but I think it helps.
March 30th, 2007 at 7:28 pm
Your articles are of good depth into human aspects of software development along-with technical bits.
I really enjoy reading them.
One of the recent blog post entry by “Coding Horror” comes to my mind.
Critique the code, not the coder (one of the ten commandments of the “egoless programming”)
March 30th, 2007 at 7:40 pm
I’m not sure this problem is directly related to coding. It’s more to do with office politics. It happens in some companies that people are vilified without reason or justification. If that person isn’t around to defend themselves, because they’ve left, then the myths start to build up. It’s like chinese whispers — somebody points out a minor point about the person, then it’s added to by another, until it becomes a full-blown proof that the individual was incompetent in some way. I’ve worked in plenty of offices where bad words have been said about somebody who’s since left, but who, on further investigation, appears to have been exemplary at their job. Some people just don’t fit in.
March 30th, 2007 at 8:27 pm
I’m not a programmer (guess the one who can’t write any code, at least yet) but I think the last line of the text should be placed in encyclopedias and be taught to children at school. There is hardly other way to become an enemy to everyone, than be better they they are.
March 30th, 2007 at 10:16 pm
I’m not a programmer, but my boyfriend is, and I had him explain what the cyclomatic complexcity is - very interesting and I learned a lot, thanks!
March 30th, 2007 at 10:45 pm
Wrong way at looking at programmer efficiency: Testing and validation is the hardest part in software development. Bob may have coded a lot but he didn’t test and validate his code. That was why other developers were pissed about all that pile of code. Bad code is one thing, but lots of good looking code that is buggy is really worse to handle.
I find that more than 50% of my code is in testing and most of my time is spent on validation. And, by the way, test code is very ugly and time consuming to generate. So having a Bob type in your team running without any checks can be a disaster no matter how good he is.
March 30th, 2007 at 10:52 pm
I hate the IT world… people are so boring and selfish… I left my first job, I got in all excited because I was one of the first in selection… but all turned in a big disappointment, and college seems to create an illusion about IT jobs…
March 30th, 2007 at 11:00 pm
In every company that I have worked as a programmer, the last person who quit is always responsible for any bugs, whether he worked on the program or not.
March 31st, 2007 at 12:18 am
Dude, I know exactly what you mean. I just left a job where things were like that. Forgive me for being a pedagogue, but for christ’s sake, get the hell out of there. Nothing good comes out of shops like that. There is better life elsewhere. Just look for it. And if I were the team lead, I’d use the first excuse I could to sack this “Mark” guy.
It’s like what Warren Buffett said. When you mix a management team with a reputation for sucess and a n industry with a reputation for bad economics, it’s the reputation of the industry that survives. The caveat is that you can change things if you are in a position to hire, fire and promote people. But if you aren’t, don’t expect the guy in charge to do anything. If he would, he would’ve done so already.
March 31st, 2007 at 1:01 am
It took a long time for me to start getting work at companies where people seemed to actually work as a team, for the same goal, instead of just to show off how their skills are better than the people around them. I still struggle with many bad habits as a result of spending so long in that kind of environment. In many ways, getting away from coding and programming all the time helped, especially taking on a part-time position coaching a local youth orchestra, and seeing the students start to go down the same path, and helping them understand that it’s not the best way to live.
Maybe it’s a symptom present in any environment where people have spent their time becoming good at what they do, but not improving who they are…
March 31st, 2007 at 2:43 am
Hi, I would like to say thanks for this cool writing. I could have been a “Bob” once, luckily I know of no feedback from my legacy.
Entertaining!
March 31st, 2007 at 2:45 am
Bob might have been an asshole. Or maybe Mark hates Bob because Bob is a Unitarian. In any case, Mark gave you information that led you to useful knowledge. Bob is gone and Mark’s company is worth less because of it.
March 31st, 2007 at 3:41 pm
One cool thing I noticed about this post… I use the google suggest thing that tracks your search terms and suggests popular search terms based on what you’ve been searching for. I noticed that #2 for today was “cyclomatic complexity”. I knew what it was when I saw it in the post, but I think it’s cool that this post alone was enough to inspire enough people to type it into google that it would show up as a top tech search term for the day. Props on such a great post.
April 1st, 2007 at 1:50 am
[…] In software no good deed goes unpunished The tale of Bob and his “Bob code”. A really good read. (tags: software programming) […]
April 1st, 2007 at 2:45 am
Great post, a lot of the programmers at our firm hate me and my buddy because we finish our code ridiculously fast, but alas, like you pointed out, we do get stuck with the blame for a good half of the bugs that come up, just because we wrote about half the code here.
Great anecdote, I enjoyed it.
April 1st, 2007 at 4:42 am
Maybe Bob wrote more lines of code because he didn’t take the time to test it? I would suggest that maybe he didn’t take the time to refactor it, either, but you went and read the code and saw that his code was better factored than everybody else’s.
It could also be a style clash; collective code ownership usually only works with good style guidelines. It sounds like Bob’s code is in a different style than everyone else’s, too, which could be a cause for friction — entirely unrelated to code quality.
April 1st, 2007 at 4:57 pm
[…] The Insider Travel Blog wrote an interesting post today onHere’s a quick excerptI had an all-too-familiar conversation with an engineer the other day (we’ll call him Mark). As I was reviewing a bunch of code that the company had written, every time Mark would encounter code written by a particular individual (we’ll … […]
April 1st, 2007 at 8:52 pm
I have noticed a similar pattern of behaviour wherever I have worked in the past.
It seems that if you’re prepared to bust a gut and get your hands dirty, it only builds resentment in those around you.
If you do more work, it is likely that you will make more mistakes. However, if you appear to be threatening the status quo then those around you will be keen to jump on any errors you make and hold them up as an example of why things should never change.
Such is life. It shouldn’t be, but it is.
April 5th, 2007 at 1:02 pm
A brilliant post.
It touches on the difference between perception and reality, and politics crippling what sounds like good work.
I’m glad Bob got out of there. To remain in that organisation would probably be poison for him.
April 5th, 2007 at 11:04 pm
Thanks to everyone for the great comments. It’s interesting to see how common this situation is.
April 16th, 2007 at 10:11 am
[…] In software no good deed goes unpunished In software there is often a large disconnect between perception and reality. This is a clear example of such a disconnect. […]
June 5th, 2007 at 4:28 pm
That was a great post. great example too. thanks.
June 17th, 2007 at 2:38 am
Code Craft » In software no good deed goes unpunished
[…][…]
November 9th, 2007 at 11:34 am
I have experienced this myself, where people were telling me how bad or awful someone’s code was but when I actually reviewed the person’s code, there was nothing horrible, out of the ordinary, or against best practices with this guy’s code. But whenever something went wrong with the system or something looked like it was running inefficiently, it became all too easy to blame this person’s code (even though the issue could have been completely unrelated to code - for example, environment-related issues). Everyone latched on to this ready-made excuse: other developers, architects, CIO, network infrastructure guys. It got to the point that when this developer left and I had to take over his work, every explanation I gave regarding an existing bug had to be accompanied with the statement “It’s not my code”.
I’m pretty sure that I will leave the same “legacy” as this developer did when I leave. Things that go wrong with the system, code-related or not, will undoubtedly be attributed to “my code” if people continue to formulate opinions without actually doing any examination. Why do I fear this is what will happen? Because it’s become too convenient to do and it’s always easier to blame the voiceless.