mike.mainguy

I read with interest an article about picking the right metric to incentivize desired behavior and thought I would add a little of my own personal insight. One problem with many (maybe most) software development organizations is that they inadvertently create perverse incentives , rewarding undesireable behavior and creating confusing and chaotic environments that, despite best efforts of all involved, seem to only on a hit or miss basis produce the desired result. Just as important, often the rewards are implicit and it isn't obvious that developers are actually being rewarded for the errant behavior. Some short examples of widely used, but poor metrics I've observed as well as some simple and arguably better alternatives follow. For example: Rewarding developers for "count of bugs fixed". Without accountability for who created the bug, this simply incents developers to release buggy half finished softwa...

As a die hard refactorer, but also pragmatic programmer, I often have a tough time articulating to other developers when a refactor is important and when it is gratuitous. I can imagine many people look at decisions I've made about when it is and isn't appropriate and think it's simply a whim or "when I feel like it". To clarify this for both myself and any future victims/co workers involved with refactoring decisions I may make, I submit this 10 item checklist. Is the cyclomatic complexity of the function below 5? Did you completely understand what cyclomatic complexity was without following that link? Do you have an automated test or documented test case for every path through the function? Do all of the existing test cases pass? Can you explain the function and all it's edge cases to me in less than 1 minute? If not, how about 5 minutes? 10 minutes? Are there fewer than 100 lines of code in the function (including comments)? Can you find two o...

Having lived through numerous attempts to build software embracing the concepts behind the agile manifesto , I feel there are three large categories folks fall into when talking about agile principles. The curmudgen - these folks have been writing code since punchcards where the state of the art, OR they have been brainwashed by large consulting organizations into thinking that a large heavyweight process is the only way to succeed. Note, a subset of these folks believe that "no process" is actually OK and are quite happy to cowboy-code their way through life. The fanboy - these folks think "everything agile all the time" and will rename status meetings to "scrums". These are folks who are used to working solo on projects that they can do in their heads... or they are simply not clued into the implications of actually having a repeatable process or delivering working software. The apologetic - these folks understand the principles and the value they...