API not changes

I have been to Configuration Management meeting this week. The topic was pre-checkin validations. I will write about them later, but now I want to talk about small sub-topic that was raised during this meeting: description of checkin.

For example, I check-in some file. Let's say README.txt. A little, 19-inch wide, window pops up where I have to fill in few fields. Some of them are completely sensible and some are over the top in my opinion. The entire practice of describing the checkin is totally common. Once I myself defined log format and implemented some system for enforcing long-enough comments. However, the devil is in the details.

In this constellation, there are quite a bit more fields than just a formatted description. For example:

• code reviewer. What the hell?!?!? If you don't trust me enough to checkin the code, why pay me money at all?
• Unit-test: passed, failed, not applicable. Once again. If I, as a professional developer, decide that this code is good enough to be checked-in, then let me decide whether unit tests should be executed or not. Do not make it a-must.
• UI changes. I can understand the need for it, but does it mean that I checkin a code that should have UI, but does not have. Meaning that there is no way to use this code right now? In addition it means, that I have checked in partial code, as some of the code is missing (UI part), which is exactly this field is about.

There were other fields, but one of the managers wanted a new checkbox called: "API change". The reasoning was that: "I want to know that API has changed as it is important. It can break other modules".

First. If you checkin a code that breaks other modules, then you are doing it wrong. Checkbox or no checkbox.

Second, API changes are not dangerous. They are visible. They break build, things stop working. The dangerous changes are those that do not change API, but change the behavior of the code. Class signature remains the same, but its logic changes. These are the dangerous changes.

So maybe there should be a checkbox: "Dangerous change". If the developer feels that the code he just checked-in is dangerous, he should check it. Probably, there should also be a reason to explain why this code is dangerous. Maybe, another field with a name of the person who approved checkin of a dangerous code.

This idea can be taken even further. There might be a checkbox called: "There is a bug in this checkin".