Brain Dead Code Award Given to Cameron Purdy


Blogs: Brain Dead Code Award Given to Cameron Purdy

  1. In his blog, long-time active member of the TSS community Cameron Purdy has given himself the Brain Dead Code award. However there seems to be a conflict of interest here as Cam wrote the code, tested the code and now sometime later has discovered the defect in the code. The code fragment in question: public boolean isEmpty() { return size() > 0; } What had Cam shaking his head was knowledge that something like this could slip through his QA process (we all know how things like this get written). The first clue was that this method is in an abstract class and all of the tests worked against concrete implementations. A take-away from this? How should/can we test abstract implementations? Obviously using concrete implementations presented some difficulties.
    Fortunately, all the existing sub-classes (both abstract and concrete) had better ideas on how to implement the method more efficiently (not to mention correctly)
    In the conclusion, Cam writes that he believes that we can achieve a zero-defect rate but questions the current set of tools capacity to help us achieve this. Cam arguably belongs in the top echelon of developers; yet he created this simple bug and the processes that he set up to catch it initially failed. Considering all of this, is Zero Defect Software achievable?

    Threaded Messages (12)

  2. Been there, done that. I've often thought about a language that combines simple state handling with OWL-like manipulation that allow properties to be inferred, rather than directly calculated. Eg. Define a generic property SIZE as an integer Define a generic property EMPTY as "SIZE = 0" So, for an array of integers, SIZE is defined as the number of items. No need to define isEmpty() as EMPTY can be inferred. Is this Prolog? I never used it. Hey ho, Friday PM. Back to work... Kit
  3. I would have been surprise if by using TDD he still create both the test and the code the wrong way. With some test coverage he will have seen he didn't test the method. Jester would also have detected the problem. So if he had followed best practices and run common free tools the mistake would not have been undetected for long.
  4. I did exactly that just this week...found the bug as soon as I wrote a Junit test.
  5. I did exactly that just this week...found the bug as soon as I wrote a Junit test.
    Hmm, you are right. JUnit tests CAN catch a lot of things, even of this kind. The issue here is that someone (eventually US, DEV guys) has to write those tests, even for extremly simple methods. Perhaps an IDE plugin to generate skeletons for the JUnit tests would help a lot (placing the necessarry TODO statments so that we remember to fill in).
  6. It's abstract![ Go to top ]

    You missed the point of the article: the class is abstract so you cannot write a test against it. You need to write a concrete subclass just to be able to test that particular method since all existing concrete subclasses override it. A test coverage tool would have indicated that this method is never tested. A few strategies that might help: - Don't write the abstract implementation until you actually need it. No code, no bug. Of course this is only possible when you control this code and can immediately add the method when you write a concrete subclass that doesn't need to override this basic implementation. - Write a minimal concrete subclass to test it. I question the value of tests that are more complex than the code being tested though. - Design by Contract would have found the problem as soon as the code is used the first time. Guus
  7. Re: It's abstract![ Go to top ]

    If all concrete subclasses override the method, then the method should not be implemented in abstract class at all, but just declared as abstract in the abstract class! So, this is also error in design, which no unit test could not (and should not) detect. These kind of errors possibly could be detected by some code inspection tool.
  8. Re: It's abstract![ Go to top ]

    It's a game of percentages really isn't it. DBC would have reduced the % chance of this surviving (as did writing unit tests for the concrete implementation). Trouble is the DBC statement might have said the same thing also, so it only reduces the chances of it surviving not eliminate it. You can't beat peer reviews, another set of eyes can be much more effective than unit testing, DBC etc. by itself. Again, still a game of percentages.
  9. Extends is evil[ Go to top ]

    This is why extends is evil. Allen Holub wrote an article on the subject titled "Why extends is evil". You have to read his article! Summary "Most good designers avoid implementation inheritance (the extends relationship) like the plague. As much as 80 percent of your code should be written entirely in terms of interfaces, not concrete base classes. The Gang of Four Design Patterns book, in fact, is largely about how to replace implementation inheritance with interface inheritance. This article describes why designers have such odd beliefs." (August 1, 2003) By Allen Holub
  10. I just wonder, are we throwing mud at CAM, or are we trying to be among the geek community, where every one is looking for a scratch in another ones eye, while we remain blind;) Zero defect Software is achievable, if there is a zero defect human, with a zero defect mind and thought, untained by fatique, and ever fresh as a summer rain;)
  11. very good![ Go to top ]

    very good!
  12. Experienced developer's fate[ Go to top ]

    This is a bug that's usually introduced by experienced programmers. They're working hard to avoid bugs that are hard to track. Bugs like those slip through because they are just to obvious to be seen by them. Code review or pair programming do not necessary help here. Coworkers will notice that this is code from a programmer who knows his craft an thus, there will be a good reason why he did it that way. In "DeBUGGING JAVA" by W.D.Mitchell, the author suggests seeding the code with "artificial" bugs. When people fix these bugs, they will fix the "natural" ones too. Maybe that prectice is the only one that could help detecting such kind of bugs.
  13. Why are you writing code in the abstract method? any ways it would be overridden....right?