More on Technical Debt #2/2

Last week I offered some techniques for management of technical debt. In this post I offer some more.

Technical debt is a debt that you incur every time you avoid doing the right thing (like refactoring, removing duplication/redundancy), thereby letting the code quality deteriorate over time. As with financial debt, it is the easy thing to do in the short term; however, over time, you pay interest on this debt - the code quality deteriorates over time. And as with real debt, it can be used beneficially if managed well.

1. Refactor technical debt away. Apply several forms of refactoring, including code refactoring, data model refactoring, and report interface refactoring. Refactorings are typically very small, such as renaming an operation or splitting a data mart column, so should just be part of everyday development. Rework, on the other hand, is more substantive and should be explicitly planned. The Architecture owner (see below) will often negotiate rework-oriented work items with the Product Owner (the person on the team who is responsible for prioritising the work).

2. Regression test continuously. One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly. This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.

3. Have an explicit architecture owner. The Architecture Owner (AO) should be responsible for guiding the team through technical decisions, particularly those at the architecture level. AOs often mentor other team members in design skills, skills that should help them to avoid injecting new technical debt into the environment. They should also be on the lookout for existing technical debt and where appropriate motivate the team to address that technical debt when appropriate.

4. Do a bit of up front thinking. Develop a technical strategy early-on in your project. By thinking through critical technical issues before you implement your solution, you have the opportunity to avoid a technical strategy which needs to be reworked at a future date. The most effective way to deal with technical debt is to avoid it in the first place.

5. Be enterprise aware. Good development teams are enterprise aware, realising that what they do should leverage and enhance the overall organisational ecosystem. They will work close with your enterprise architects, so that they can take advantage of existing IT assets. An important strategy for avoiding technical debt is to reuse existing assets and not rebuild or rebuy something that you already have.

Manage your debt and it will pay you back; pay no attention to it and you may end-up with a credit bubble!

200,000 and Growing

Yay! We just topped 200,000 hits on the blog. Since I started it in 2009, I've posted 433 posts on the NOTE: blog. I'm humbled that people continue to find the content interesting. Keep tuning in!

More on Technical Debt #1/2

Last year I introduced the topic of technical debt. Technical debt is a debt that you incur every time you avoid doing the right thing (like refactoring, removing duplication/redundancy), thereby letting the code quality deteriorate over time. As with financial debt, it is the easy thing to do in the short term; however, over time, you pay interest on this debt - the code quality deteriorates over time. And as with real debt, it can be used beneficially if managed well.

I thought I'd list a few of the techniques I use to manage debt. I'll list five here, and offer some more in a subsequent post.

1. Reduce the debt before implementation. Passing systems with high technical debt to other teams, such as a systems operation team is generally a bad practice. It should be ingrained in your culture that each team is responsible for keeping the quality of their solutions high. It is reasonable to expect maintenance groups to resist accepting systems that have high technical debt.

2. Some technical debt is acceptable. Sometimes you will decide to explicitly accept some short term technical debt for tactical reasons. Perhaps there is a new component or framework about to be delivered by another group in your organisation, so you’re writing a small portion of what you need for now until you can replace it with the more robust component. Regardless of the reason, part of the decision to accept technical debt is to also accept the need to pay it down at some point in the future. Having good regression testing plans in place assures that refactoring accepted technical debt in the future can be done with low risk.

3. Measure technical debt. If you are serious about technical debt then you must measure it and, more importantly, keep an eye on the trends (which should be going down over time). Keep a log of technical debt that identifies each element.

4. Explicitly govern your technical debt. For your organisation to succeed at reducing technical debt it must be governed. This means it needs to be understood by senior management, measured (see previous point), and funded.

5. Make the reduction of technical debt part of your culture. Technical debt isn't going to fix itself, and worse yet will accrue "interest" over time in the form of slower and more expensive evolution of your system.

As with real debt, technical debt can be used positively if it is well managed. Using the above techniques will help you to manage it.

Read more:
More on Technical Debt #2/2

NOTE: Additional SAS Professionals in London

Whilst the scheduling of the international Analytics 2013 event in London in June (hosted by SAS) precluded the annual SAS Professionals conference, we're being treated to a series of SAS Professionals Roadshow events in Marlow, London and Dublin (and Scotland and Manchester early next year). I attended the Marlow event in October and found it most informative. I wrote about it at the time (here, here and here).

It seems that the upcoming London event has proved more popular than anticipated and so SAS have added an extra date. December 11th is sold-out, but December 12th is now available to be booked. The SAS Professionals web site has full details. If you're not already signed-up for a date, don't miss your opportunity for the new date. Book ASAP!

NOTE: More Agility at SAS

Last month I featured an article by SAS's Tim Arthur regarding the adoption of agile techniques at SAS. Tim promised to produce another article in November, and he has been good to his word.

In 5 More Ways SAS Scaled Agile Scrum, Tim focuses on coaching options, communication, scale, and closing the loop. All of these topics are focused on increasing the adoption of agile around the organisation. Judging by the speed with which new versions of Visual Analytics are being released, the agile approach is making a positive difference at SAS.

Good tips from Tim. I'd add the following that are specifically related to agile planning:

• Split the project into short iterations. By working in short iterations of 2 - 4 weeks each, and being sure to deliver working software at the end of each, you get a true measure of your progress


• Only create detailed plans for imminent tasks. Schedule in detail weeks ahead but not months; use a high-level plan for the months ahead. In practice, this usually means producing a detailed plan for the next couple of iterations


• Ensure the people doing the work are actively involved in scheduling. They have the skills and knowledge, plus the motivation to get it right. And it ensures they buy in to the plan


• Allow people to choose their work, don't assign it. Again, this ensures commitment and buy-in


• Take a requirement-centred approach. Centre your plan around delivering features or user stories rather than the traditional design, build, test activities


• Remember training. If agile is new to your enterprise, remember to include training for new staff, and refresher sessions for existing staff

Good luck with your agile project.

NOTE: Interactive Metadata-Bound Libraries (MBLs)

Further to my recent note on SAS V9.4 updates, Metacoda's Paul Homes recently highlighted something that had slipped my attention: a point-and-click interface for creating metadata-bound libraries (MBLs).

In Paul's Creating a Metadata Bound Library with SAS 9.4 article he describes the SAS management console method for interactively defining an MBL, thereby avoiding the need to use PROC AUTHLIB. I mentioned this in an article in May this year but had overlooked it since.

I'm a big fan of metadata-bound libraries and, as Paul says, "this is a great addition to SAS Management Console 9.4" and it will certainly increase the take-up and use of MBLs. Paul's article contains a step-by-step guide to using this feature, along with plenty of screenshots.

NOTE: Visual Analytics to Replace PowerPoint?

I noted Tricia Aanderud's recent post on BI Notes with a wry smile: Can SAS Visual Analytics Replace PowerPoint for a Small Business? The question seems incredulous, yet when I read Tricia's article in full, I could see sense in the train of thought that Tricia and some of her clients were propounding.

If you spend a lot of time preparing slide decks full of charts, read Tricia's article and see if you might support her argument too. It's certainly thought-provoking, and amply demonstrates many benefits of Visual Analytics.

NOTE: SAS Talks Archive - A Treasure Trove of Training Goodness

In last week's post on Enterprise Guide custom tasks I mentioned a video in the SAS Talks archive. Some of you wrote to me to say that the archive was difficult to find; I have to agree.

SAS Talks is an ongoing series of monthly webinars from SAS. The subject matter is wide and varied. The presenters range from SAS's own staff through to SAS customers. The topics are generally technical and range from Base SAS syntax though to use of Enterprise Miner and Enterprise Guide.

You can view the upcoming schedule from the SAS Talks web page; be sure to register if you intend attending an upcoming session.

The SAS Talks home page also includes links to a curated set of highlights, but if you really want to dig into the treasure trove of sessions, you need to look for the link to the archive in the introductory paragraph at the top of the page, or click the link at the very bottom of the page.

To receive email information about new talks, you can subscribe.

See also the Expert Channel at SAS Professionals, another veritable vault of valuables.

Note to self: alter your approach with regard to articles, all of this alliteration is alarmingly annoying some of the audience!

NOTE: Spicing-Up Your Enterprise Guide With Custom Tasks - Checking Cardinality

Last week I wrote about a couple of neat custom tasks from Metacoda that would allow you to search metadata from within Enterprise Guide (EG) and the Add-In for Microsoft Office (AMO). Custom tasks are a great way to augment the functionality you get in EG and AMO.

I recently saw Chris Hemedinger write in The SAS Dummy blog about a custom task to check cardinality that he'd written. If you're into hierarchies, dimensions or forms of analytics, cardinality is doubtless a frequently used part of your vocabulary. In essence, cardinality of a variable specifies the number of distinct values of that variable.

Back in May, Chris published some good advice about installing custom tasks, taking into account changes made in EG 5.1 and later. Worth a read.

If you're new to the idea of custom tasks, the SAS Talks archive contains a one hour Introduction to Custom Tasks video from earlier this year.

If you would like to broaden your knowledge of custom tasks and start to write some for yourself, I highly recommend Chris's book Custom Tasks for SAS Enterprise Guide using Microsoft .NET. Examples from the book (with source) are available too.

All-in-all, if you haven't already given attention to custom tasks, you've no longer got any excuse to ignore them!