One of the things I learned from my tenure as a software project manager was that a project is more likely to succeed if there’s a way to get where you want to go continuously. You want to move a project from A to B gradually, keeping a working code base all along the way. At the end of each day, the software may not be fully functional, but it should at least build. Anything that requires a big bang change, tearing the system apart for several days and putting it back together, is less likely to succeed.
This is very much like the idea of homotopy from topology, a continuous deformation of one thing into another. No discontinuities along the way—no ripping, no jumping suddenly from one thing to another.
3 thoughts on “Agile software development and homotopy”
Interesting metaphor! “Builds” is probably a sufficiently soft constraint to make the whole space of reasonable programs (including “Hello, world!”) path-connected, but I wonder what happens when you add the sometimes implicit constraint of “made ‘enough’ progress during the $time-unit” for some eldritch customer-driven meaning of “enough.” That certainly blocks some paths, which might make the space not path-connected anymore. A depressing thought, that.
Anyway, maybe I’m over-stretching the metaphor (I keep thinking there’s a way to make a topology pun off that phrase, but I couldn’t figure out one).
This is also important if you’re learning: The most frustrating thing when learning something (along with all the other “most frustrating things” ) is thinking that there’s a discontinuous jump from the knowledge you have to the knowledge you want.
For example, tutorials which top out at the basics and leave you with no apparent path to anything middling-complex; real code is fairly complicated for many reasons, so learning from it is an exercise in seeing past the complexity of what you don’t care about to be able to see the complexity of what you do care about. This is daunting if your last foray into the subject topped out at a dozen lines and one or two independent concepts.
Think of it as a positive-sum game in which every move must leave the game in a valid state: builds and passes all tests.