The three line rule

A frustrating couple days of coding has crystalized a new rule for me:

If you can’t demonstrate your new feature in three lines of code, you’re not done.

But it works from the client UI? Great. And it’s fully tested? Super! But you’re still not done.

If it took twenty lines of setup code to make the unit tests work, you’re not done. There should be a close to one-to-one correspondence between artifacts in the UI and artifacts in your codebase. Did you add a new command? There should be a single methodthat encapsulates that command. Did you add a new form? There should be a single classwhich can be instantiated in a valid state with a single constructor or factory call.

I’m not saying this just for the sake of style. This is for your own good. It’s so that six months from now, you can look at that feature on the screen and track it to a single point in the code. It’s so that when you’re training the new guy, you can open up a console and type three lines to demonstrate how that feature works. It’s so that when you write a conference presentation on your brilliant code, you can fit the examples on one slide.

Don’t just be a domain expert; be an API designer. A humane one. The brain you may save from imploding is your own.

I don’t have time to go into technical details, but the Facade pattern is your friend.