In the last month I've encountered the term Technical Debt a great many times. If the term is unknown to you, consider it a sort of borrowing against your future (e.g., time in most cases, but also money to pay for employees' time) in order to more quickly deliver something now (e.g., a software product). Technical debt is what happens when you don't do now the proper work you'll have to do later.
It's not hard to imagine why we would begin to think about the work we do as software developers in terms that map onto the world most discussed of late by the news media. The over saturation of news coverage devoted to the financial crisis, subprime mortgages, financial bailouts, etc. has caused many of us to privilege certain metaphors because they come so easily to mind, and seem to be most characteristic to our time. The ready-to-hand of the financial metaphor makes its meaning and assumptions harder to see, since it's all we see, and how can that which we see be anything other than that which is?
Today I was reading Martin Fowler discuss what he categorizes as the four types of technical debt. He does a good job making the case that technical debt needs to be divided into four quadrants: "reckless/prudent and deliberate/inadvertent." To say that borrowing is always reckless is clearly wrong. However, to only imagine it on a continuum from reckless to prudent misses something too: was the debt taken on deliberately or inadvertently? Does the team understand the costs of their choices? Are they choosing to pay-off the interest now, knowing they'll have a period coming later on when the principle can be tackled? Or, is the team naive and working faster than they are careful?
It's a good analysis, but the sentence that really resonated with me was this one:
Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking.
Fowler recognizes the limits of his procedure from the beginning, and more, he draws attention to the mechanism by which it works. In doing so he implicitly asks an important question: are there other metaphors that would be as, or more helpful? I think there are.
Part of why the financial metaphor works so well for software is that most of the people I see using it are working on software that is being sold as a product. In this sense, the fact that it is software is really secondary to its primary meaning: they are building "apps" for the "store." There's another kind of software, though, and this other kind of software is where I do almost all of my work. The software I'm working on day to day is open source, and much of it represents the building of tools, libraries, and other meta-software as opposed to end-user products. I mention this not to pass any kind of moral or ethical judgment, but to try and further loosen the de facto link between software development and a financial metaphor of debt.
So if not debt, then what? Just as the financial metaphor is used because of its fitness and readiness, as seen by its users, I am drawn to the metaphor of writing. We can already make a case for the appropriateness when we listen to ourselves talk of "writing software," "creating libraries," "documenting our code," etc. The movement toward a metaphor of writing gets the backs of some of my colleagues up, who begin to hear overtones of "software as art" vs. "software as science." You'll forgive me if I seem to sidestep this problem, since I don't see the distinction as absolute. Writing can be artistic, can be scientific, can move fluidly between the two. We never expect writing proper to decide once and for all whether it is art or science, and nor should we have a similar expectation when we invoke it as metaphor.
What happens when we replace the image of the bank approved loan for that of the writer working on a text? First we notice that the implied contract that existed between ourselves and an unnamed institution, which had the power to lend what we didn't have, is replaced by something we can refer to in shorthand as the tradition. The tradition is the context out of which we work. Where the institution is legally structured, the tradition is historically structured. To replace the institution with the tradition is to give up certain rights and responsibilities in order to adopt a more tentative and dynamic relationship with what has come before.
Writing still obliges us. Writing is never free of the tradition, is never isolated, even, and especially, when it pretends to be original. Writing-as-reading is only available via the backdrop of the writing that precedes it. Writing-as-writing always points back to what has come before, whether by assuming the conventions of form or the language, using shared images and phrasing, or by creating itself out of, or on top of existing texts.
When we replace the idea of capital obtained through borrowing with the availability of the constellation of ideas, forms, images, language, etc. of the tradition, I think we arrive at an interesting place in which to think about the writing of software. Instead of thinking only about the product, and doing so in isolation, we start to use words like influence and _ reaction_. The process of writing software starts to look less like goal-oriented work, and instead emphasizes ' just writing something', doing it with discipline, reworking what you've written, throwing things away, quantity over quality tempered with merciless editing and being willing to start over (again). Software-as-writing also looks a lot less assured and professional while it's being created. It flounders, grows out of experiments, moves fast then slow, gets stuck at critical sections. It is always drawing on what one knows or is seeing in other similar writing. The idea that it gets easier, that you can master it, that it's just a matter of "time plus materials"--that's what comes of thinking about this like building houses. But it's not like a house. It's like a book, like an autobiography: it has to be lived and written simultaneously.
Above all, software-as-writing helps to humble you. You're not paying down a debt you can measure. Instead, you're working against the limits of yourself, of the language, and of the tradition. You are necessarily outmatched and under prepared. If you take your eyes off your empty emacs buffer long enough to notice the company you're among, it can feel hopeless some days, and inspiring to be with them the next. And you're never done. You have to decide to stop at some point, which isn't the same as working off a fixed cost. There's no good way to measure a lot of what lies before you when you start.
Software-as-writing is just as flawed as technical debt, perhaps more so. However, it more closely resembles what I've come to understand about the process of creating software. It mimics my existence and experience working on big software projects. It's no more a universal than is the experience of writing is: it looks quite different to different writers. But all of them will agree that it's hard. It's hard and it's endlessly inspiring work.