Loading ...
Sorry, an error occurred while loading the content.

In software no good deed goes unpunished

Expand Messages
  • Mahbubul Karim (Sohel)
    In software no good deed goes unpunished For tech enthusiasts the following article published in Code Craft
    Message 1 of 2 , Apr 1, 2007

      In software no good deed goes unpunished

      For tech enthusiasts the following article published in Code Craft states the obvious moral of the story in its very last line:
      "If the culture is broken, the fastest way to make enemies is to do more than everyone around you." Not much different from other fields.

      Mahbubul Karim (Sohel)

      Read the full article from the following link:
      In software no good deed goes unpunished

      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.