CCD Red Degree Retrospective

Well I’ve been wearing the Orange bracelet for a while but I haven’t been thinking about it too much. Before I get back into the Clean Code Developer series of posts here is a quick recap of what you should be doing to consider the Red level "mastered":

  1. You must Stay DRY. Ruthlessly eliminate duplication. Look for implicit concepts in your code and make them explicit. Extract, encapsulate and pretty please, no clipboard inheritance. Try to remember that the best programmers delete code.

  2. You should Reflect Daily. And not by calling Object.GetType(). Actively look at what you are doing. Don’t just think it, write it down. Re-read it. Engage your brain in actively reinforcing the things you do right and altering your behaviour to avoid those things you don’t do right. If you do this every day you can’t help but become a better programmer.

  3. You adhere to The Boy Scout Rule. For such a simple idea this has very powerful consequences. You can’t help but check in code and if each check-in makes your code easier to work with then that’s a recipe for success. Good little boy scouts can DRY up their code, they can analyse issues with Root Cause Analysis, they can ensure that everything required for a build is in Source Control and they can Apply Simple Refactorings. Remember that the day you stop improving it is the day your code is starting to rot.

  4. Put as much as is reasonable in Source Control. It doesn’t matter which one. It doesn’t matter if you don’t think you need one yet. You will need one. They are easy to use and there are good free ones available. There is no excuse for not using a Version Control System. In this era of Distributed Version Control Systems you don’t even need a server. Just do it.

  5. Apply Root Cause Analysis. Look beyond the symptoms and see the problem. Ask why. And then ask why again. Keep going until you get to real issue and then fix it so it never shows up again. Examine each bug as if it were a process problem (trust me it probably is) and adjust your process accordingly.

  6. Know when to optimize. Almost never comes to mind. That doesn’t make it okay to right slow code, it just means that you should focus readability first. After all, if it’s slow and readable then someone else has a chance of being able to speed it up. If it’s fast and incomprehensible then no-one will ever tough it again. Factor out the part of the code you want to optimize so that different implementations can be slotted in. Never optimize without measurements to back up your decision and to verify your improvements.

  7. Apply Simple Refactorings. You’d be surprised how much more readable software can become just by using Rename and Extract Method. You don’t need powerful tools to do this (although any version of Visual Studio will do both out of the box). Don’t be scared about having lots and lots of little methods. If we are (re-)naming them appropriately then our toolset provides a number of navigational aids to help us move around our code.

  8. Keep It Simple Stupid. Prefer the simplest solution to any problem. Be aware when you are adding complexity and understand the reasons why. Try to remember the business value in what you are doing and ask if the client is willing to pay for the extra “scalability”, “flexibility” or “excuse to explore cool new thing X”.

8 simple steps but they are a good start down a long road. If you’re still with me then prepare to take off the Red band, wash your wrist and put on the Orange band.

Posted by: Mike Minutillo
Last revised: 27 May, 2011 04:39 PM History


04 Nov, 2010 09:31 AM @ version 0

Thanks for a very effective summary; the linked posts are really insightful.

No new comments are allowed on this post.