that is directly linked to a failed functionality. Breaking the issues down means you can more clearly identify code that is signed off and ready for production instead of being questionable. Most directly, it’s frustrating for a developer who now has to parse out which part of the code base is viable and which is not, while tracking dependencies. It will almost certainly take more time to split out code than it would have to start with individual issues. Most issue tracking systems are user friendly and do not take any significant amount of time to enter issues.
This can't be tested, just put it in production.
This gem is more often a failure of imagination than it is a resource issue. Many project teams will say it can’t be tested because of various systemic issues. And that may be the case. But commonly, a testing team pressed for time, because it’s their time getting cut first, will just agree with the assessment and skip the work. Putting untested code into a production release is truly a last resort effort. Depending on the type of software you are working with, code failures may be far more expensive than the delay being avoided.
It was only one line of code, what's the big deal?
It’s the same as untested code. Changing a line of code, even a comment, has been known to cost companies significantly. I know of one case directly where a comment was added post testing but the developer inadvertently failed to close the comment causing more than $3 million in product correction. One line of comment, not even code, sparked a completely avoidable, and expensive, event. Developers often view it as an insult to their ability or trustworthiness. It’s simply good business sense. As the Gipper put it, “Trust, but verify.”
No, no, we use a serious CM tool -- VSS!
This is no dig on that goliath software company; it’s simply a recognition of what constitutes a CM tool. A good CM tool will allow the user to both version control the code and then relate a version to various releases or issues and the maturity of each version in the lifecycle. Being able aggregate the code at that build/release/issue tracking level provides a significant amount of change control that is at the heart of configuration management. It should allow the administrator to define at least some level of process within the tool for the benefit of its users. I pick on Visual SourceSafe not because it’s made by a particular company or fails to do what it’s not designed to do. I use it here as an example of how project staff misunderstand the function and practice of good configuration management. A good CM tool should allow you to channel users in good, defined process to make it easier on them and accelerate their work.
I'll just modify the file in production. We can copy it to the repository later.
Uggh. Production support teams, development teams, anyone with access to the production servers are under tremendous pressure to get things running again. There is always money on the line. But this particular comment is geared toward individuals who are not production support. Many organizations have processes in place to work prod fixes back into the code base. It’s not a preferred arrangement but then doing business often forces certain compromises on us. This is for the character that’s hacking on