Developer Superstition

Superstition is a bad thing. At least that’s what I have always believed, regarding myself as totally devoid of the stuff. I mean, me, Mats Henricson, superstitious? No way!

But superstition grows out of ignorance, and that’s a valley I must admit I have walked in. And some time ago it struck me that I am indeed plagued by superstition as a developer. Let me elaborate.

Suppose you’re in a slow edit-compile-debug cycle, and suddenly your changes to file X aren’t deployed to Tomcat any more. After some brief investigation it turns out you can get your changes through to Tomcat by prepending your Maven command with "clean", i.e. a clean compile, instead of just incremental.

At this moment your are in dangerous territory, because if you never find the root cause to the problem you are quite likely to ALWAYS do clean builds, thus slowing you down forever!

Does this resemble a situation in your past? If so, then you are also superstitious!

I have added all sorts of shit procedures to my daily work. I do WAY to many clean builds. I restart my laptop twice a day because I can’t get it to dynamically go from wireless to wire, or from my second screen at work to my second screen at home, since they are of different size. My Ubuntu 9.10 distro have problems with that, and I just haven’t found the root cause to it.

Staving off superstition is simple in theory but hard in practice, since it requires you to go to the root of the cause of problems. I have suddenly gotten much more respect for stubborn people!

5 responses on “Developer Superstition

  1. Interesting subject. I clearly recognize the situation, but I don’t regard myself as being superstitious just because I do a clean build “just to be sure”. Sometimes you must use the sledgehammer to get forward, even though the screwdriver would have been enough if you would have found the screw hole.

  2. Is this really superstition?

    Isn’t it simply a trade-off?

    Always making a clean build or restarting the laptop is a proven work-around for a known issue, and the time it takes to work-around the issue is known in advance.

    Finding the root cause may take an hour, or the whole day, or even longer. And it still need to be worked around until it is also corrected.

    As humans, I think we tend to prefer the known (workaround) to the unknown (finding and correcting the root cause).

    But… what is most lean?

  3. Interesting subject. Here are a few of my superstitions:

    • When searching for a difficult to find bug in an unknown environment, doing log.fatal() instead of log.debug() to be sure that the message will be seen.
    • When a unit test succeeds the first time it runs (i.e. not doing TDD), editing it so it will fail to make sure that it is run.
    • Instead of doing build and run with one command (e.g. ant run), doing it in two steps just in case the build fails but the build environment doesn’t notice.

    All of these can be related to a badly set up development and runtime environment. If you can’t trust your tools and frameworks to behave the way you expect them to, you get superstitious and start wasting time on workarounds. As previous posters have stated, this may be the right thing to do if the workarounds waste less time than fixing the root cause. (But I guess you should factor in the decreased productivity from programmers feeling they are not 100% sure what they are doing.)

  4. In Andy Hunt’s Book “Pragmatic Programming” this is called programming by coincidence. I would recommend every programs to read this book.

Leave a Reply to David Eriksson Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.