When Adding Complexity – Just in Time Beats Just in Case

It’s better to introduce complexity into your code “Just in Time” rather than “Just in Case”.

Let’s make this ultra flexible, Just in Case someone wants to do x, y and z.
Let’s split this into a new library, Just in Case we need it elsewhere.
Let’s optimize this piece of code, Just in Case it’s too slow.

They’re really going to want a, b or c (not x, y and z).
It’s easy to create that new library later, when you know you need it.
A profiler will tell you what parts are slow.

If all the Just in Cases were saved until Just in Time… there would be time to refactor, there would be time to do more testing and the code would be more maintainable.

You should think about the Just in Cases, but don’t implement them yet… (unless it has to do with testing).

This entry was posted on Thursday, July 28th, 2011 at 6:27 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  1. Sebastián Grignoli says:
    July 28, 2011 at 6:55 am

    Could you illustrate with a real world example of a case where separating into a new library was a bad idea? I have tons of examples of the opposite.

  2. Paolo Losi says:
    July 28, 2011 at 8:17 am

    @Sebastian

    good: separate into a new library just in time
    bad: separate into a new library just in case

    +1!

  3. Vivin Paliath says:
    July 28, 2011 at 11:04 am

    This combines “Premature Optimization” and “YAGNI”. :)

  1. There are no trackbacks for this post yet.

Leave a Reply