All debt is credit. The only differences are who it is going to, and when.
So what should our goals be?
Less code means fewer features, which can make the UX path longer. More code means more features, which can make the UX path more confusing and strenuous. There is some kind of balance to be struck. The goal is for every UX path to be flexible and easy. Is that even possible? Can we have our cake and eat it, too?
> Adding new assumptions increases debt
There's the word I have been thinking about all week: "assumption". It's a tricky little bastard, and it really deserves more focus than it has any right to.
You see, that word is the heart of our problem. It's not the amount of code you write, the features you add, the way you design your UI/UX, or even how flexible your user configuration is. It's the assumptions themselves.
Assumptions are walls. Once an assumption has been added, it’s there to stay. It's easy to move an assumption around. Too easy! So easy that you move it without even knowing; but it is still there, lurking. No matter how hard you try to get rid of it, or to get around it, the assumption is guaranteed to stand in your path. Your only hope is that the assumption is there to guide you; its only other option is to guard you.
So what can we do about it? We can not. No need to get rid of something you never made in the first place, right?
But how do you make software that is unassuming? How can you make a tool without catering that tool to its intended work? How can you make a path without a destination?
There's something we have gotten notoriously used to as software engineers: a finished product. After all, what else would an engineer strive to make?
Finished products are things. Programs aren't. Programs are systems! Programs are stories. What kind of system is ever finished? I can only think of one: a dead one. At the end of its life, a system becomes cold, hard, sturdy, and complete; and the story meets its end. How did we ever convince ourselves that that is a worthy goal for software?
I'll tell you how: we assumed. That assumption has been lurking at the heart of software design ever since, and all we can do now is move it. It's time to start over.
---
This is where I answer my very first question: who? Who designs the software? Don't assume it's the engineer's job: it's the user's turn now.
The next question is, when? When does the user design their software? When they use it. Any time before that would make them an engineer.
What should our goals be? That's the best part! The user already knows her goal. That makes her precisely the right man for the job.
---
If you followed any of my rambling so far, you are probably asking yourself the most important question, "What could this possibly look like?" That's a good question. I have something really close to a coherent idea. If you would like to hear about it, feel free to ask.
So what should our goals be?
Less code means fewer features, which can make the UX path longer. More code means more features, which can make the UX path more confusing and strenuous. There is some kind of balance to be struck. The goal is for every UX path to be flexible and easy. Is that even possible? Can we have our cake and eat it, too?
> Adding new assumptions increases debt
There's the word I have been thinking about all week: "assumption". It's a tricky little bastard, and it really deserves more focus than it has any right to.
You see, that word is the heart of our problem. It's not the amount of code you write, the features you add, the way you design your UI/UX, or even how flexible your user configuration is. It's the assumptions themselves.
Assumptions are walls. Once an assumption has been added, it’s there to stay. It's easy to move an assumption around. Too easy! So easy that you move it without even knowing; but it is still there, lurking. No matter how hard you try to get rid of it, or to get around it, the assumption is guaranteed to stand in your path. Your only hope is that the assumption is there to guide you; its only other option is to guard you.
So what can we do about it? We can not. No need to get rid of something you never made in the first place, right?
But how do you make software that is unassuming? How can you make a tool without catering that tool to its intended work? How can you make a path without a destination?
There's something we have gotten notoriously used to as software engineers: a finished product. After all, what else would an engineer strive to make?
Finished products are things. Programs aren't. Programs are systems! Programs are stories. What kind of system is ever finished? I can only think of one: a dead one. At the end of its life, a system becomes cold, hard, sturdy, and complete; and the story meets its end. How did we ever convince ourselves that that is a worthy goal for software?
I'll tell you how: we assumed. That assumption has been lurking at the heart of software design ever since, and all we can do now is move it. It's time to start over.
---
This is where I answer my very first question: who? Who designs the software? Don't assume it's the engineer's job: it's the user's turn now.
The next question is, when? When does the user design their software? When they use it. Any time before that would make them an engineer.
What should our goals be? That's the best part! The user already knows her goal. That makes her precisely the right man for the job.
---
If you followed any of my rambling so far, you are probably asking yourself the most important question, "What could this possibly look like?" That's a good question. I have something really close to a coherent idea. If you would like to hear about it, feel free to ask.