Dummy Code (Quick’n'Dirty vs. Engineered)
When creating software, two people will never write the same implementation of a method or system of non-trivial design. Creating software is a problem solving process and there are usually many ways to solve one problem. The solutions may differ in elegance and efficiency while giving the same output for a given set of inputs. A correct solutions is a correct solution regardless of implementation.
Building software modules within a team requires communicating, at a minimum, method or class signatures and a general idea of the functionality. This may include a detailed design document clearly specifying method signature and a pseudo-code implementation or method stubs and comments about what the method should do right in the source file. One thing that should never be used for communicating a signature and functionality is dummy code.
Dummy code looks like real code. It is real code but it rarely works. Even if it compiles it doesn’t produce the correct result when run. Nor are there any tests that prove it (in)correct. Dummy code exists only for the sake of its author’s gratification.
Rather than talk about the desired functionality through some more productive means the dummy code author thinks he is helpfully providing a guesstimate of correct implementation. What he has actually done is provide a jumbled mess of non-working code cleverly disguised as a working part of the project when he checks it in to the SCM. The dummy code author thinks someone else will come along and provide the correct implementation “later”.
What he doesn’t realize is that his dummy code is almost indistinguishable from code that should be part of the project. The next person to try to reuse this code is in for hours of WTF moments trying to figure out WTF the code is supposed to do and why it’s got code branching five levels deep.
At my first post-college job I had a wonderful mentor. Thys (pronounced Tays, like “taste” without the second ‘t’) and I were talking one day when he asked me a question. “Anthony, if you were given a task of writing software that would only be run once would you do it quick-and-dirty or with a well-measured, engineered approach?”
How bad could “quick-and-diry” be if the software would run only once? I thought about it for a moment before answering. Quick and dirty.
Thys said he would never write quick and dirty software. Doing so figuratively creates a monkey on the developerment team’s back. The software that only needs to run once inevitably needs to run a second time and a third time and eventually run regularly. Thys helped me realize that software evolves and escapes. Useful software will run indefinitely. Any time and effort saved on the initial write will be lost 10 times (I made that number up. It is actually higher. Any want to provide real data or examples?) over on the maintenance, bug fixes and rewrites.
Writing dummy code is writing software quick and dirty without any idea of the implementation details. Bad code and bad algorithms. The worst of both worlds. It’s been a long time since Thys and I had that conversation but the years have proven him right again and again. Any code worth checking in to SCM is worth writing well. That includes unit tests.
Dummy code has no place in SCM. If you’re not going to correctly implement a method you stub out then don’t provide an implementation at all. Leave some comments around the method stub if you have to. Open a ticket in the issue tracking system to let someone know the method needs an implementation and describe the input and output. Let the implementer determine which algorithms and data structures to use.
Dummy code is a hazard to software projects. It violates the principle of least astonishment. Next time you think about writing some remember that the next person that uses the code will waste time figuring out why it doesn’t work as expected.
If you check code in to your SCM where other people can pull it, take a look at what you’re checking in. Does it work? Does it work well? Are there tests that prove it? Helping someone by coding less is sometimes the best help of all.
