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.

Published by Avdi Grimm

23 Comments

  1. and those three lines should be
    create it
    start it
    stop it

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

    When there is time, can the technical details be spelled out? I can sort of guess at the end result, but I fear I'll miss the true magic of what you're getting at.

    Reply
  3. I have a similar rule…

    You should be able to explain any given function in your code to your own grandmother. If you can't, then you're not done.

    The essence of programming is to be able to break down complex problems into simple sub-problems.

    If you don't aquire that skill, you will not be a good programmer. Imo.

    Reply
  4. how true. Nice tip. Thanks.

    Reply
  5. […] The three line rule If you can’t demonstrate your new feature in three lines of code, you’re not done. […]

    Reply
  6. Hmm, anything more than two lines is overkill.

    Reply
  7. I have a similar rule…

    You should be able to explain any given function in your code to your own grandmother. If you can't, then you're not done.

    The essence of programming is to be able to break down complex problems into simple sub-problems.

    If you don't aquire that skill, you will not be a good programmer. Imo.

    Reply
  8. how true. Nice tip. Thanks.

    Reply
  9. No destroy or reallocate?

    Reply
  10. I wouldn't like to explain bind (>>=) to my grandmother. Does that make it a bad function?

    Reply
  11. “When one function loves another function very much…”

    Reply
  12. Or:
    Create it
    Act on it
    Show the result of the action.

    Reply
  13. Sure, I'll put it on my list of posts to write.

    Reply
  14. Hmm, anything more than two lines is overkill.

    Reply
  15. The rule is modified for Perl programmers to “13 characters or less”.

    Reply

Leave a Reply

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