Tag: lifecycle

Not necessarily a title you’d expect for a blog post, I guess*, but I’m a fan of technical debt. There are two reasons for this: a Bad Reason[tm] and a Good Reason[tm]. I’ll be up front about the Bad Reason first, and then explain why even that isn’t really a reason to love it. I’ll then tackle the Good Reason, and you’ll nod along in agreement.

The Bad Reason I love technical debt

We’ll get this out of the way, then, shall we? The Bad Reason is that, well, there’s just lots of it, it’s interesting, it keeps me in a job, and it always provides a reason, as a security architect, for me to get involved in** projects that might give me something new to look at. I suppose those aren’t all bad things, and it can also be a bit depressing, because there’s always so much of it, it’s not always interesting, and sometimes I need to get involved even when I might have better things to do.

And what’s worse is that it almost always seems to be security-related, and it’s always there. That’s the bad part.

Security, we all know, is the piece that so often gets left out, or tacked on at the end, or done in half the time that it deserves, or done by people who have half an idea, but don’t quite fully grasp it. I should be clear at this point: I’m not saying that this last reason is those people’s fault. That people know they need security it fantastic. If we (the security folks) or we (the organisation) haven’t done a good enough job in making security resources – whether people, training or sufficient visibility – available to those people who need it, then the fact that they’re trying is a great, and something we can work on. Let’s call that a positive. Or at least a reason for hope***.

The Good Reason I love technical debt

So let’s get on to the other reason: the legitimate reason. I love technical debt when it’s named.

What does that mean?

So, we all get that technical debt is a bad thing. It’s what happens when you make decisions for pragmatic reasons which are likely to come back and bite you later in a project’s lifecycle. Here are a few classic examples that relate to security:

not getting round to applying authentication or authorisation controls on APIs which might at some point be public;

lumping capabilities together so that it’s difficult to separate out appropriate roles later on;

hard-coding roles in ways which don’t allow for customisation by people who may use your application in different ways to those that you initially considered;

hard-coding cipher suites for cryptographic protocols, rather than putting them in a config file where they can be changed or selected later.

There are lots more, of course, but those are just a few which jump out at me, and which I’ve seen over the years. Technical debt means making decisions which will mean more work later on to fix them. And that can’t be good, can it?

Well, there are two words in the preceding paragraph or two which should make us happy: they are “decisions” and “pragmatic”. Because in order for something to be named technical debt, I’d argue, it needs to have been subject to conscious decision-making, and for trade-offs to have been made – hopefully for rational reasons. Those reasons may be many and various – lack of qualified resources; project deadlines; lack of sufficient requirement definition – but if they’ve been made consciously, then the technical debt can be named, and if technical debt can be named, then it can be documented.

And if they’re documented, then we’re half-way there. As a security guy, I know that I can’t force everything that goes out of the door to meet all the requirements I’d like – but the same goes for the High Availability gal, the UX team, the performance folks, et al.. What we need – what we all need – is for there to exist documentation about why decisions were made, because then, when we return to the problem later on, we’ll know that it was thought about. And, what’s more, the recording of that information might even make it into product documentation, too. “This API is designed to be used in a protected environment, and should not be exposed on the public Internet” is a great piece of documentation. It may not be what a customer is looking for, but at least they know how to deploy the product now, and, crucially, it’s an opportunity for them to come back to the product manager and say, “we’d really like to deploy that particular API in this way: could you please add this as a feature request?”. Product managers like that. Very much****.

The best thing, though, is not just that named technical debt is visible technical debt, but that if you encourage your developers to document the decisions in code*****, then there’s a half-way to decent chance that they’ll record some ideas about how this should be done in the future. If you’re really lucky, they might even add some hooks in the code to make it easier (an “auth” parameter on the API which is unused in the current version, but will make API compatibility so much simpler in new releases; or cipher entry in the config file which only accepts one option now, but is at least checked by the code).

I’ve been a bit disingenuous, I know, by defining technical debt as named technical debt. But honestly, if it’s not named, then you can’t know what it is, and until you know what it is, you can’t fix it*******. My advice is this: when you’re doing a release close-down (or in your weekly stand-up: EVERY weekly stand-up), have an item to record technical debt. Name it, document it, be proud, sleep at night.

****if you’re software engineer/coder/hacker – here’s a piece of advice: learn to talk to product managers like real people, and treat them nicely. They (the better ones, at least) are invaluable allies when you need to prioritise features or have tricky trade-offs to make.

*****do this. Just do it. Documentation which isn’t at least mirrored in code isn’t real documentation******.

******don’t believe me? Talk to developers. “Who reads product documentation?” “Oh, the spec? I skimmed it. A few releases back. I think.” “I looked in the header file: couldn’t see it there.”

*******or decide not to fix it, which may also be an entirely appropriate decision.