davidlee/gist:81dea1165b09b707f7f9982f0940d17b

## gistfile1.txt
It has been aptly said that programming is the art of managing
complexity.

A large software project, in the best possible case, is understood as a
researcher understands a library. You may have read a number of the
books, and might even know a few of them intimately. If you want to find
a book – even one you've never seen before – it's usually easy as long
as you know the ISBN, the exact name, or at least the author.

You'll spend most of your time reading though, trying to find a clue or
flash of inspiration that leads you to another volume, and then
another. It's easy to take the diligent bibliographies and the
arrangement of thoughtfully ordered shelves for granted, and simply
focus on the work. This is the ideal.

At the other end of the scale: have you ever seen a documentary about a
pathological hoarder? If you can imagine attempting to perform the same
activities in this setting, with piles of magazines, receipts and old
hardcover encylopedias mouldering under plastic bags full of children's
clothes soaked in rat piss, you might think it's impossible. It's
not. It's just much, much slower going, and a very different kind of
work.

Technical debt is the name developers give to the gap between how they
have to work, and how they would like to.

# The Quality Gap

There's a platonic ideal, for any system's set of
functionality, which minimises the cost of a specific future change. Some
interesting properies of this ideal are that:

 * it changes when you make any changes to the functionality of the system
 * it changes when you change your plans
 * it changes when any programmer's understanding of the system, or those
   plans, changes (because their understanding impacts the cost of change)

But the form of that ever-changing ideal is a mystery, and credible
guesses at even its broad strokes require considerable creative and
analytical effort. We tend to call our best guess our Vision or "Light
on the Hill", although this tends to change on a time scale of months or
even years.

And then there is the Reality. We can plot these on a continuum – let's
call the axis Quality:

                    Reality                 Vision                Ideal
                       |                      |                     |
                       v                      v                     v
 ____________________________________________________________________
                              Quality


There are two gaps here: the gap between our Vision and the Ideal (or
the "Vision Gap") and the gap between our Reality and the Vision (the
"Practice Gap"). The term "technical debt" is sometimes used to cover
both of these, although we tend to use it more when discussing the
Practice Gap.

# Why don't we get it right the first time?
	It has been aptly said that programming is the art of managing
	complexity.

	A large software project, in the best possible case, is understood as a
	researcher understands a library. You may have read a number of the
	books, and might even know a few of them intimately. If you want to find
	a book – even one you've never seen before – it's usually easy as long
	as you know the ISBN, the exact name, or at least the author.

	You'll spend most of your time reading though, trying to find a clue or
	flash of inspiration that leads you to another volume, and then
	another. It's easy to take the diligent bibliographies and the
	arrangement of thoughtfully ordered shelves for granted, and simply
	focus on the work. This is the ideal.

	At the other end of the scale: have you ever seen a documentary about a
	pathological hoarder? If you can imagine attempting to perform the same
	activities in this setting, with piles of magazines, receipts and old
	hardcover encylopedias mouldering under plastic bags full of children's
	clothes soaked in rat piss, you might think it's impossible. It's
	not. It's just much, much slower going, and a very different kind of
	work.

	Technical debt is the name developers give to the gap between how they
	have to work, and how they would like to.

	# The Quality Gap

	There's a platonic ideal, for any system's set of
	functionality, which minimises the cost of a specific future change. Some
	interesting properies of this ideal are that:

	* it changes when you make any changes to the functionality of the system
	* it changes when you change your plans
	* it changes when any programmer's understanding of the system, or those
	plans, changes (because their understanding impacts the cost of change)

	But the form of that ever-changing ideal is a mystery, and credible
	guesses at even its broad strokes require considerable creative and
	analytical effort. We tend to call our best guess our Vision or "Light
	on the Hill", although this tends to change on a time scale of months or
	even years.

	And then there is the Reality. We can plot these on a continuum – let's
	call the axis Quality:

	Reality Vision Ideal
	\| \| \|
	v v v
	____________________________________________________________________
	Quality


	There are two gaps here: the gap between our Vision and the Ideal (or
	the "Vision Gap") and the gap between our Reality and the Vision (the
	"Practice Gap"). The term "technical debt" is sometimes used to cover
	both of these, although we tend to use it more when discussing the
	Practice Gap.

	# Why don't we get it right the first time?