we (team of 15) use salesforce and a promise to include issue numbers in our (svn) commit msgs all on one dev branch so when we cherry pick merge later to qa we can “safely” assume we got it all. 30% of the time it works 10% of the time.
i can’t convince these guys code is not “self documenting” let alone use git or a tool for proper bug reporting.
I had a boss who wrote a script to automatically remove all comments from code for pull requests. Since nobody ever added meaningful comments to their commits (or made any contributions at all to the alleged documentation), the code base was a complete mystery to the people who were actually working on it. God knows what it seemed like to new developers added to the project. But hey, comments are a “code smell” (his exact words) so it was all good.
His primary justification of his “comments bad” philosophy was that if comments aren’t kept up-to-date with the code, they can mislead and confuse future developers. This gets said a lot but it is something that I have literally never seen in 25 years of programming (I’ve witnessed – and participated in – a large number of project failures, and misleading comments have never been the cause of the failure). I pointed out that the same exact thing could be said about method and variable names but nobody ever advocates not using descriptive method and variable names; he had no response to this.
we (team of 15) use salesforce and a promise to include issue numbers in our (svn) commit msgs all on one dev branch so when we cherry pick merge later to qa we can “safely” assume we got it all. 30% of the time it works 10% of the time.
i can’t convince these guys code is not “self documenting” let alone use git or a tool for proper bug reporting.
I had a boss who wrote a script to automatically remove all comments from code for pull requests. Since nobody ever added meaningful comments to their commits (or made any contributions at all to the alleged documentation), the code base was a complete mystery to the people who were actually working on it. God knows what it seemed like to new developers added to the project. But hey, comments are a “code smell” (his exact words) so it was all good.
His primary justification of his “comments bad” philosophy was that if comments aren’t kept up-to-date with the code, they can mislead and confuse future developers. This gets said a lot but it is something that I have literally never seen in 25 years of programming (I’ve witnessed – and participated in – a large number of project failures, and misleading comments have never been the cause of the failure). I pointed out that the same exact thing could be said about method and variable names but nobody ever advocates not using descriptive method and variable names; he had no response to this.