Kaizen, refactoring, and controlling the source code changes
The other day I and fellow lead of mine were chatting about general code quality issues. The person I was talking with brought up a very good point - every change you make to the code base must do what it’s supposed to do and in addition something else to make general quality of the code better. This "something else" can be very simple: rename method to make its intent clearer, extract duplicated code to separate function, "clean up" one class/file or practically apply any of the other refactorings. Some of you may realize that this is basically kaizen and refactoring mixed together ;-)
Problem during typical product cycle is that there’s something we call "open coding season" during what every change to the code base doesn’t have to have triage’s approval and then there’s a period during what every change to the code base has to get blessing from the triage team and go through lots of scrutiny to get accepted. There are a couple of reasons why there’s so much bureaucracy to get something changed late in the product cycle. I’ll mention just some of them:
- The main rationale is that software itself is extremely complex and any little change in one module can cause butterfly effect which could possibly render some feature of the product totally useless. Having a triage team with development, program management, and test representatives from every related component team ensures to some level that there’s at least some oversight in regards to what’s happening with the product. If one team will like to change something which theoretically can cause major scenario not to work, affect number of our customers, affect some other team, has great percentage of risk, has big testing impact etc., then probability that one of the people will catch this is pretty good.
- Backwards compatibility. For example you don’t want to force all your Beta customers to rewrite all their application because we just radically decided to change all the API-s or rename number of fields in DOM. From developer’s point of view very simple change - refactor the names of some fields to make them comply with new naming conventions, do quick search’n’replace on all the test-cases, change them - can cause major trouble later.
- Possibility of breaking Windows Logo requirements. If you’ve read the logo certification document you’ll understand that writing under wrong registry key or installing some files under wrong locations may ruin your product’s chance to conform to logo certification standards.
- List goes on: possibility of breaking Windows user interface guidelines, violating the accessibility standards, introducing unwanted dependencies etc.
Cool, now we reached the stage where everyone is afraid to make any changes because it has possibility of breaking everything ;-)
Fortunately it’s not so bad IRL as you may have deduced from information above. Common sense has still place in our triage room and some of us even know what EmbraceChange and RefactorMercilessly mean ;-) The above was just something to think about when choosing the proper strategy depending on your specific product and the phase of the milestone. There’s no absolute truth (á la "after the second RC you must not change anything which has to do with locking"), but one needs to have something in the middle of being extremely cautious and inflexible vs. having huge code churn every day. If you can’t change at all then you’re doomed anyway. I personally tend to incline more to the "taking risk and changing something side" rather than being very careful. Possibly because I have never been significantly bitten by the late code changes and I’m strong believer in the common sense over the process. Your mileage may vary.