The sprinkler systems are on and it’s time for Spring cleaning!  One of my favorite things to do in the Spring is to pull everything out before tidying up.  First step is to move the cars out of the driveway and start marching things out of the garage.  Clutter has a way of snowballing into a straight-up mess.  If you’re like I am, Spring Cleaning is also the time when Winter items make way for Summer items.  Removing clutter and preparing for seasonality is an opportunity in your software environment as well.  Garage mess = technical debt!

Take Stock

Your garage and my garage are probably similar, stocked with loads of useful things and some useless things.  Useful – Tools, Hardware, Gear/Sports Equipment.  Useless – Flattened boxes/overflow recycling, CDs (they had merit once), college essays (?).  But before we can assign that easy label of Useful or not, we need to know all that’s in there.  If you’re the Software Development Manager/Director or the Head of Transformation at your company, you should use a cataloging tool to list out what your software environment looks like.  Use a very simple spreadsheet with the following columns to start: Application Name, Vendor, Where Deployed, Disposition, Who Cares.  Now fill out what you know at this point about each system used by people at your company.  You may only know the name of the app and the vendor.  Some people call the ‘Who Cares’ column the ‘Business Owner’ or ‘Stakeholder’ – this is the person who will complain if this feature is ‘tidied up’ and removed and they still use it.

Assess/Plan

Think about all the things you want your software to do by the end of this year.  Begin to lay those out using a roadmapping software.  Atlassian’s Jira product has the added benefit of making your Epics something that can naturally branch out into the actual development items (stories, tasks) as you move into the next phase of Execution.  Front load (pull forward) all items that have immediate revenue impact on your business, backload those items that are useful for only a small subset of your customers.  This prioritization allows you to determine which project vehicles (a path to change) can be taxed with technical debt retirement without purely planning for technical debt retirement.  The reality of any software environment is that when you crack open the hood, it is easier/cheaper for developers to do new things and fix old things that are functionally cohesive (in the same end-state modules) than it would be to fix either independently.  Don’t stop at making a plan and DON’T hire a consultant who gives you nothing more than a plan (you know the big shops and I won’t enumerate them at risk they feel sore about it and send in their army of lawyers…).   DO hire a consultant who can help you craft a plan and see it through to completion.  And yes, in our example there are companies who’ll help you organize your life and your garage – hire them for your life, hire me for your business.  Phase Deliverable: All cataloged items from your Take Stock phase should now show a potential project vehicle that will ‘take them along for the ride’.

Execute

Start small and grow.  Imagine you have x amount of work you wanted to get done next month on your product.  Let’s say that’s 5 User Stories (or features if you think of it that way).  Reduce that by 20%.  Now you have 4 to work with.  On each of those 4 stories there MUST BE something that can be done with the existing code base to make the incremental change that much easier to maintain in the long run.  Have your team peer review the change and discuss the merits of the refactoring.  It is that much harder to do this if you’re a team of one but look yourself in the virtual mirror and ask yourself if it’s easier to maintain the software now that you’ve generalized functions and compartmentalized code into more manageable modules (not MUNGED them into a ball of hair).  In the long run this type of approach will bear two types of fruit: one (crisp apple?) – you will generate less technical debt with each incremental change you add to your product by the discipline of the approach; and 2 (pear?) – you will reduce the existing technical debt and therefore benefit from reduced defects, time to resolve defects and increased velocity on layering in change.