When I need to explain how Instant Developer came into being about a dozen years ago, I remember the context in which the software houses at the time were working: software with little testing, disconnected code, and applications that became obsolete with no hope of rescue. I saw more than one IT company literally blocked in its attempts to maintain an existing codebase, unable to develop it further. And when the first crisis hit, they folded.
And still today, the situation hasn’t changed much. In the United States, where they like to study and find a name for everything, they even came up with a term for this phenomenon that software inevitably faces: Technical Debt.
Although it was introduced twenty years ago now by Ward Cunningham, the concept of Technical Debt continues to be a central theme in software engineering management. Cunningham’s insight owes its longevity to the fact that the problems he identified continue to afflict organizations large and small, all around the world. The definition on Wikipedia is interesting to read:
“The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.”
But what does Technical Debt have to do with Instant Developer? Twelve years ago, without even realizing it, we started building Instant Developer around a new concept – a concept that proved itself to be central to addressing the problem of technical debt: relational programming.
As users of Instant Developer well know, relational programming is an innovative technique for generating code thanks to which the Instant Developer IDE saves the entire software project, the entire codebase, in a graph of relationships and dependencies rather than in tons of text files. Really. No text files. Even individual lines of code aren’t saved as strings of characters, but rather as nodes in a network that keeps them interconnected.
The more complex the software project being developed, the better Instant Developer works. To help explain why, we’d like to take a closer look into the origins and causes of Technical Debt, so we’re inviting you to follow us through a short series of posts in this blog over the next few weeks.
In the meantime, here’s some food for thought: have you ever considered that as you’re developing software, at that very moment you’re getting into debt (technically)?
In this series:
- Technical Debt #1: Getting closer to debt-free programming
- Technical Debt #2: Where it comes from
- Technical Debt #3: Learning to handle it
- Technical Debt #4: Eliminating it at the source