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...

A great many people starting out with java development have only a vague understanding of the difference between a "public static String", "public String", and the difference between a class and an object. As this was confusing to me at first, I thought I would give a quick overview. A class defines a template for what data and operations are available when you tell the JVM to create an object. So, for example: class BlogPost { public BlogPost(String inString) { text = inString; BlogPost.latest = this; } public String text = ""; public static BlogPost latest; } When you do the following BlogPost myPost = new BlogPost("Hello"); You're telling the JVM to allocate some memory on the heap to store a reference to a memory location and from now on, when I refer to myPost, it means that memory location. BlogPost is a class, myPost is an Object that is a reference to a memory location that is an ins...

Having studiously avoided Oracle for over 20 years, I'm now working in a shop that uses it almost exclusively. Aside from the general overall expense of the product I'm routinely amazed at how many features other DBMS's I've used (DB2, MSSQL, MySQL, PostGres) are either missing or syntactically difficult to understand. The most recent example is server side pagination… or more specifically, having the DBMS limit the results returned to for specific subsets of rows. In oracle to do this, one must run a query something like this: select * from (select name, rownum rn from (select name from users order by name) where rownum 5; I realize that this is a legacy syntax, but I personally find the new way just as obtuse. The new way (I guess) is supposed to be: select * from (select name, row_number() over (order by name) rn FROM users) where rn between 5 and 10 order by rn Compare this with the syntax for mySql (also now...

I'm a long time linux user, I installed my first distro in 1994, it was slackware and required a bunch of floppies and was a fairly painful process. Over the years, I migrated from slackware to redhat and finally settled on Ubuntu as my "daily driver". Every computer in our house (a server, three laptops, and two netbooks) is currently funning a flavor of Ubuntu and I decided to give setting up my work machine (macbook pro) with Ubuntu. The big reason I like Ubuntu is that they are doing a good job of making an operating system (OS) that finds a great balance between "you can do anything you want" and "I just want it to work". Ubuntu has thousands of free software packages that are tested and verified to work that will install with the click of a button. Windows and OSX are so far behind in this regard as to not even be contenders. While there is a little more technical knowledge necessary to get Ubuntu up and running, it typically has so many r...

So borrowing an idea from the NCO Creed , I thought I do one for software developers: D iscipline will be my watchword, the software I create will never be perfect, but I will perform my job to the best of my abilities and remember that every letter I type should have purpose. E go is the enemy of good code, I will remember that "I am not my code" and never fail to admit mistakes and fix in in a humble manner. V alue is provided not through MORE code, but less. My software will be succinct. E nergy overshadows ability, I will bring my "A" game and not give up because it's "too hard". L ove for my users is always in my heart, they will break my code, I will fix it O penness wins over closedness, I will share my tips and secrets and together we'll all make the world a better place. P atience is paramount, sometimes the answer isn't the first, second, or fiftieth idea. E mpathy for the newbie and the uninformed wins, you never know when t...