Software Best Practices

My present client wants all work checked into source control on a daily basis.

Question: Why?

Client response: We want to monitor what developers are doing every day.

Question: What happens if the code is incomplete and will break the build?

Client response: Developers should comment out code that will break the build prior to check in.

Does anybody have any response suggestions, or recommendations on version control resources?

Thanks,

Malcolm

 Seems like a waste of time to me. Developers now have to spend the time to comment and checkin at end of day, then checkout and uncomment at beginning of day? And for a dubious metric?

We use StarTeam here, its OK. It was an improvement over old Visual SourceSafe, don't know if MS Team has a better tool now.  

This is a classic mistake of 'Mistaking Activity for Progress."

I can understand the client’s desire for monitoring. However, for a well tracked project, the manager, and the team, must know with clarity the status in four dimensions -- functionality, quality, cost, and schedule.  I'm sure that they can argue that monitoring code check in is proxy for functionality.  But it is a incomplete and faulty measure.  It puts an undue emphasis on coding and ignores all the other critical software engineering activities. Worst yet, forcing the team to check in incomplete work increases the effort. It introduces non-value added work or "waste" in lean terms. It almost like going on a trip and monitoring miles per gallon and ignoring that you are driving around in circles.

Effective project managers have numerous, more productive and accurate, means for monitoring status and gaining insights into the team's activities. Your client needs to take the time to learn them.

Good luck,

Checking in work daily is a valuable development tactic for two reasons: to avoid losing work and to reduce integration friction. The longer you wait to check in your work, the more rework you will have to do if your local copy is lost or corrupted. And the longer you wait the greater chance for merge conflicts that must be resolved.

 
Code that will break the build should not be checked into the main branch. You should create a special branch for code that requires a longer timeline until it can be integrated. Then you can check in your code daily to this branch without breaking the build. Of course, this mitigates the risk of lost local work, but it doesn’t address the issue of merge conflicts. Eventually, this special branch must be merged back to the main branch, and conflicts will need to be resolved at that time.

 
The comment about monitoring what developers are doing every day indicates to me a low-trust, micro-managed environment. This is not a version control issue, but a process and management issue. The question isn’t why should we do daily check ins, but why is there an atmosphere of distrust at our company? That’s a much bigger question…