Document Note: 2009 interview where Ward Cunningham reflects on the metaphor of "Technical Debt"
Key point is not so much that you can afford to write poor software and catch up later, the core principle is about how well you understand the problem and how well you understand the software that you have created.
If the software does not properly reflect your current understanding of the problem, then refactoring will be harder than it should be.
if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your
understanding of those features then eventually that program simply does not contain any understanding in all efforts to work on it to take longer or longer in other words the interest is total you'll make zero progress (View Highlight)