Don't commit half-ready implementation. It will (at least one of this)
- break the build
- break the (busines) logic
- cause bugs
- obfuscate team members. (Dude, who performed a mid-task integration? Now George is all obfuscated; call the manager, we're going to need to refactor George before continuing.) (Sorry, I couldn't resist.)
I will do exactly this. Rember,
SeparatePolicyAndMechanism. I will often checkin the mechanism early with a policy that is do not apply mechanism in any case.
So your principle is to apply anti-YagNi? You check it in even when it can be demonstrated that you don't need it?
This is highly dependent on your
VersionManagement software. It is very helpful to have a system that can commit changes, but not apply them to the mainline build (yet). This gives a good rollback point to base further work on, without disturbing other developers.
For example, with git, you can commit many times to a private branch your local repository, and push your changes to the lead developer only when they are ready for integration. See
ExtremeVersionControl.