When to checkin?

The archaic bad advice is:

Don't check in code that doesn't work!

Why is it wrong?

• It confuses two things that should be decoupled: checkin (for identification purposes), and publication
• It assumes that management only concerns working code, i.e. is not available during the development itself!
• It assumes that all the SCM tools are as primitive as the only ones the author knows
• It pretends to set up a tool independent process, whereas it is heavily bound to prehistorical tools

One could almost state the contrary: once the code works (and you won't change it anymore), you don't need to manage it.
Management is needed precisely when things change, when there are problems to solve, advice to receive, solutions to negociate with others, test cases to write and to see fail!

In fact, in an agile mind frame, one should:

• write the test case
• run it to see it fail
• record the failure
• fix the code
• run the test case again and see it pass
• record the success.

The two records (in ClearCase: audited configuration records) should allow a later user to reproduce the events and to trace the difference in behaviour to the difference in the code, thus replacing documentation with runnable tests!.
Quite obviously, this implies that the non-running code is checked in!

In any case, you learn of failures only afterwards, when a non expected failure happens, in a context you did not anticipate. So, the advice above is just impossible to follow! Or incredibly naive.
There exists no working code: only code that is not known to break yet.
The only code that won't ever break is shelfware.

-- MarcGirod - 07 May 2009