"Write Everything Twice" and "Because What If I Need It Later"

April 1, 2009

Programmers are concerned with the number of lines of code they write in their programs. There is this idea that the fewer lines of code you write the better. This is a hold over from the days of tiny hard drives measured in Kilobytes, a far cry from today's standard of measuring hard drives in hundreds of Gigabytes or even Terabytes. We no longer need to convolute our programs with abstractions simply to save on the number of lines. This is why I'm advocating the "Write Everything Twice", or the WET principle. The next time you have a method or function in your code that does something and you want to use that function in another place in your code, but have it function slightly different, just simply copy and paste the original method and alter the copy. You've heard it said time and time again. Disk space is cheap, which in turn means lines of code are cheap.

Another closely related principle is "Because What If I Need It Later", or BWIINIL (pronounced ba-WIN-null). Many programmers are lazy in that when they develop an application, they sometimes only write the code for that features that they think they need at that moment. What they don't realize is that there is significant mental cost of switching back into the context of that part of the code a later date. Any time you are writing code you should say to yourself "What else might I need later?".

One particularly good way to apply the BWIINIL principle is to get the book Design Patters: Elements of Reusable Object-Oriented Software, which is more commonly know as the Gang of Four book, and attempt to apply every pattern in the book to every method you write. This will allow you to insert layers upon layers of abstraction and indirection that may seem like overkill at first, but will come in handy some day when you are adding new features.

Here's an excellent real word example taken from Uncyclopedia. We'll all familiar with this trivial implementation of HelloWorld in Java:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

This kind of code is often included in books about Java, which is understandably watered down for programmers first learning Java. But if you really want to graduate to that next level and write a professional, enterprise-ready implementation of Hello World, you need this:

interface Printer {
    void print(Message message);
}

class Message {
    private String message;

    public Message(String message) {
        this.message = message;
    }

    public void print(Printer printer) {
        printer.print(this);
    }

    public String toString() {
        return message;
    }
}

abstract class AbstractPrinterFactory {
    public static AbstractPrinterFactory getFactory() {
        return new SystemOutPrinterFactory();
    }

    public abstract Printer getPrinter();
}

class SystemOutPrinterFactory extends AbstractPrinterFactory {
    public Printer getPrinter() {
        return new SystemOutPrinter();
    }
}

class SystemOutPrinter implements Printer {
    public void print(Message message) {
        System.out.println(message);
    }
}

class HelloWorld {
    public static void main(String[] args) {
        Message message = new Message("Hello, World!");
        AbstractPrinterFactory factory = AbstractPrinterFactory.getFactory();
        Printer printer = factory.getPrinter();
        message.print(printer);
    }
}

Also make sure to include UML class diagrams that shows how these components interact. Once you learn to embrace the WET and BWIINIL principles and apply them to your everyday coding, I'm sure you'll quickly see an increase in the quantity...er, I mean....quality of your code.

Posted in Technology | Tags AprilFools, Java

Comments

1.

nice post...

i would propose extending the BWIINIL mindset: assume that all code you write will be used by someone else, as if all the stuff you write is for a third party, or you are writing an SDK for someone else to use.

it will help you question the overall design, think in terms of reusability, and ensuring that the public (and even private) interface for your methods is intuitive and well thought out. personally, it has really made me think in terms of smaller units of work, making methods more generic (within reason), and avoiding dduplication/copy-paste of code.

if you assume that someone else will be using the code, it strokes the ego a bit, too .... who wants to have someone look at their code and say, "wtf is this?!"

coming from a product background, this added time to my initial coding, but subsequent releases were easier as i had built up a "toolbox" of reusable code/components. my team was able to share a ton, saving a lot work between our individual projects. this applied many platforms, from javascript, to COM components, to XSLTs. In the long run, it allowed us to focus on the new business logic, rather than reworking the plumbing.

# Posted By jim on Wednesday, April 1 2009 at 9:09 AM

2.

^^^ wow

# Posted By John Trupiano on Wednesday, April 1 2009 at 8:27 PM

Comments Disabled