I'd just like to put the timescales mentioned here into perspective from a different type of software system. My experience of development has been providing online services in the form of web applications, so that means our customers don't need to install anything. That means our release process is different from the one mentioned in the question: it sounds a lot easier and quicker.
But any errors we introduce can impact the business severely, and in these cases 48 hours is just too long to fix a critical error. In such cases we need to take a view on how much the error is affecting our customers. If a high percentage of customers are affected then it needs to be fixed ASAP, but if only a small percentage is affected then a longer time can be taken to fix the error.
In our case it comes down to how much business we'll lose by not fixing the error.
Most of the arguments for in depth comments are actually tell tale signs that code needs to be refactored. I don't think this article gives too good examples on how to comment you code, and it seems the author doesn't have too much experience in team programming with a fluid code base.
Some code will always require a comment, but if you can write code that doesn't require one, then IMO that's better than masking unnecessary code complexities with comments.
Slashdot Mirror
Don't forget the hazelnut conspiracy
I'd just like to put the timescales mentioned here into perspective from a different type of software system. My experience of development has been providing online services in the form of web applications, so that means our customers don't need to install anything. That means our release process is different from the one mentioned in the question: it sounds a lot easier and quicker.
But any errors we introduce can impact the business severely, and in these cases 48 hours is just too long to fix a critical error. In such cases we need to take a view on how much the error is affecting our customers. If a high percentage of customers are affected then it needs to be fixed ASAP, but if only a small percentage is affected then a longer time can be taken to fix the error.
In our case it comes down to how much business we'll lose by not fixing the error.
http://devproj20.blogspot.com/2007/11/how-fast-is-your-turnaround-time.html
Most of the arguments for in depth comments are actually tell tale signs that code needs to be refactored. I don't think this article gives too good examples on how to comment you code, and it seems the author doesn't have too much experience in team programming with a fluid code base.
Some code will always require a comment, but if you can write code that doesn't require one, then IMO that's better than masking unnecessary code complexities with comments.