Comments for Code Buddy http://www.codebuddy.co.uk Ramblings from the Coding Trenches Fri, 25 Dec 2009 09:53:34 +0000 http://wordpress.org/?v=2.9 hourly 1 Comment on That’s Not My Code! by Andreas Grech http://www.codebuddy.co.uk/thats-not-my-code/comment-page-1/#comment-468 Andreas Grech Fri, 25 Dec 2009 09:53:34 +0000 http://www.codebuddy.co.uk/?p=433#comment-468 That's not my code. It doesn't work. That’s not my code. It doesn’t work.

]]> Comment on 4 Steps to Painless SVN Branching by codebuddy http://www.codebuddy.co.uk/4-steps-to-painless-svn-branching/comment-page-1/#comment-184 codebuddy Tue, 24 Nov 2009 09:47:20 +0000 http://www.codebuddy.co.uk/?p=258#comment-184 Thanks Findlers, I'll give that a go next time I'm working in a branch - looks like a great little tool, I'd not heard of it before! Thanks Findlers, I’ll give that a go next time I’m working in a branch – looks like a great little tool, I’d not heard of it before!

]]> Comment on 4 Steps to Painless SVN Branching by Findlers McGiven http://www.codebuddy.co.uk/4-steps-to-painless-svn-branching/comment-page-1/#comment-183 Findlers McGiven Tue, 24 Nov 2009 09:39:44 +0000 http://www.codebuddy.co.uk/?p=258#comment-183 You might also consider using the Python tool SVNMerge, http://www.orcaware.com/svn/wiki/Svnmerge.py. I wrote a guide for it a few years back, http://progblog.wordpress.com/2007/02/21/automatic-branch-merging-with-svnmerge-on-subversion/. You might also consider using the Python tool SVNMerge, http://www.orcaware.com/svn/wiki/Svnmerge.py. I wrote a guide for it a few years back, http://progblog.wordpress.com/2007/02/21/automatic-branch-merging-with-svnmerge-on-subversion/.

]]> Comment on Are You Stuck In The Maintaince Programmer Mindset? by Peter Kofler http://www.codebuddy.co.uk/are-you-a-stuck-in-the-maintaince-programmer-mindset/comment-page-1/#comment-12 Peter Kofler Thu, 22 Oct 2009 09:42:19 +0000 http://www.codebuddy.co.uk/?p=256#comment-12 Nice approach trying to determine the maintenance mindset and constant whining. Good idea! But I disagree with your list of actions. Maintenance is a wider area and also contains adding new functions from time to time. In my experience it's also "maintenance mindset" to not think about stuff and e.g. keep adding classes after classes of same boilerplate code without structure. It's more about thinking how to add than adding itself. Also refactoring larger scopes (several classes) should be added to your list. I would expect refactorings to be required in maintenance quite often, still not done... Nice approach trying to determine the maintenance mindset and constant whining. Good idea! But I disagree with your list of actions. Maintenance is a wider area and also contains adding new functions from time to time. In my experience it’s also “maintenance mindset” to not think about stuff and e.g. keep adding classes after classes of same boilerplate code without structure. It’s more about thinking how to add than adding itself. Also refactoring larger scopes (several classes) should be added to your list. I would expect refactorings to be required in maintenance quite often, still not done…

]]> Comment on 4 Things To Consider When Fixing a Bug by Giorgio Sironi http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-8 Giorgio Sironi Wed, 09 Sep 2009 21:32:30 +0000 http://codebuddy.wordpress.com/?p=10#comment-8 Good checklist. I like the TDD way of thinking. Good checklist. I like the TDD way of thinking.

]]> Comment on 4 Things To Consider When Fixing a Bug by choy http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-7 choy Wed, 09 Sep 2009 07:55:16 +0000 http://codebuddy.wordpress.com/?p=10#comment-7 Is it really a bug? It may very well be a *feature* that many users (inside and outside the team) are dependent on. e.g. SHStripMneumonic is misspelled. Is it really a bug?

It may very well be a *feature* that many users (inside and outside the team) are dependent on. e.g. SHStripMneumonic is misspelled.

]]> Comment on 4 Things To Consider When Fixing a Bug by Kim Greenlee http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-6 Kim Greenlee Tue, 08 Sep 2009 04:08:47 +0000 http://codebuddy.wordpress.com/?p=10#comment-6 #5 Know the history. Use the version control system to determine when the bug was introduced. Was the bug created as a result of trying to fix something else? Has it been in there a really long time? If the bug has been in there for a long time and didn’t manifest…what changed? This is one of the main reasons why when you check-in code changes that are associated to a bug or enhancement in your tracking system, that you record the tracking system number in the check-in notes. Additionally, I would recommend that folks use good judgment on #1. While in the general cases what you suggest is just fine and for valid reasons…if the code is in a section that needs high performance…too many checks will degrade your application’s performance and could cause problems from a customer perspective and in some cases may impact SLAs. #5 Know the history. Use the version control system to determine when the bug was introduced. Was the bug created as a result of trying to fix something else? Has it been in there a really long time? If the bug has been in there for a long time and didn’t manifest…what changed? This is one of the main reasons why when you check-in code changes that are associated to a bug or enhancement in your tracking system, that you record the tracking system number in the check-in notes.

Additionally, I would recommend that folks use good judgment on #1. While in the general cases what you suggest is just fine and for valid reasons…if the code is in a section that needs high performance…too many checks will degrade your application’s performance and could cause problems from a customer perspective and in some cases may impact SLAs.

]]> Comment on 4 Things To Consider When Fixing a Bug by Barry Kelly http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-5 Barry Kelly Tue, 08 Sep 2009 04:00:23 +0000 http://codebuddy.wordpress.com/?p=10#comment-5 Disagree somewhat substantially with point 1: hard to track down bugs are usually in legacy and/or complicated code, where understanding of invariants is woolly or lost in mists of time and staff turnover. Writing good diagnostics beyond basic logging is not easy, precisely because your knowledge of the invariants are woolly. Sometimes the only way to get good diagnostics is to rewrite the thing, and if it's too complicated, that may not be a good value proposition for the business; so you just have to live with it, and fix other issues when and if they come up. Disagree slightly with point 4: do mention what the bug is, a one-liner description of the symptom or cause of the bug. This helps hugely in reviewing change logs looking for breaking changes in a team environment - a bug number or other cross-reference means you have to open up a separate data silo and hugely slows down what should be 3-second a visual scan. Disagree somewhat substantially with point 1: hard to track down bugs are usually in legacy and/or complicated code, where understanding of invariants is woolly or lost in mists of time and staff turnover. Writing good diagnostics beyond basic logging is not easy, precisely because your knowledge of the invariants are woolly. Sometimes the only way to get good diagnostics is to rewrite the thing, and if it’s too complicated, that may not be a good value proposition for the business; so you just have to live with it, and fix other issues when and if they come up.

Disagree slightly with point 4: do mention what the bug is, a one-liner description of the symptom or cause of the bug. This helps hugely in reviewing change logs looking for breaking changes in a team environment – a bug number or other cross-reference means you have to open up a separate data silo and hugely slows down what should be 3-second a visual scan.

]]> Comment on 4 Things To Consider When Fixing a Bug by Null http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-4 Null Tue, 08 Sep 2009 02:43:41 +0000 http://codebuddy.wordpress.com/?p=10#comment-4 You forgot: What test cases are there to test your fix against? You forgot: What test cases are there to test your fix against?

]]> Comment on 4 Things To Consider When Fixing a Bug by mehblah http://www.codebuddy.co.uk/4-things-to-consider-when-fixing-a-bug/comment-page-1/#comment-3 mehblah Mon, 07 Sep 2009 21:56:13 +0000 http://codebuddy.wordpress.com/?p=10#comment-3 You missed the most important point to consider when dealing with badly written systems and BEFORE fixing the bug. Is anything else dependent on the bug? You missed the most important point to consider when dealing with badly written systems and BEFORE fixing the bug.

Is anything else dependent on the bug?

]]>