Spike or steel thread. Something I failed to mention is that you should be prepared to do this in the messiest possible way. Manual steps are just fine. The first time.
In addition to the mess, there also should be an expectation that some parts are going to be thrown out. That is, some work will need to be thrown out and re-done.
To play devil’s advocate, I would say that there is nothing that is more permanent than a temporary solution. In other words, the prototype that you/team meant to rewrite/throw away may become de-facto standard, because (1) it does the job already, and (2) priorities changed and all of the people need to jump on something else...
Permanent temporary solutions don't bother me any more. There's always a fantasy world where everything is perfectly designed, but that project's dead because it failed to deliver in time. The best of all actually possible worlds is the one in which repair keeps up with damage.
~80% of the software cost is in maintenance. Putting together a messy solution quickly is cheap and it gets the job done and is certainly better than project death (assuming your project is actually needed). The challenge and the question is who and how is going to pay to maintenance? I have read some startup people say that maintenance is a Champaign problem... I don’t know if I believe it, because maintenance starts the day your system is in production.
I feel like we have gone a full circle and came back to the iterative development: build the end-to-end working system as fast as you can, when it starts to break under load, fix it just enough, when adding features becomes hard, refactor it just enough to enable the feature development (ensuring that the cost of refactoring is lower than the benefit that the newly enabled features will bring). So is this “just” action bias and iterative development?
Some engineers look at the process you describe & imagine how much better it could be if only they had time to design everything properly from the beginning. I gave up on that vision since it never matched reality. The times I "had the time", I overengineered the system to the point it didn't work at all. Instead, I embrace the suck & focus on gratitude for still being alive.
I know something like manual steps would be a mental blocker for me on this. Not saying it should be, just that I've cultivated a bit of an aversion to them over the years. I think that's often a good thing, but I know it would be something I'd have to consciously set aside, and probably correctly so in this case.
Isn't this what some people call a spike? I often use the phrase "vertical slice" to communicate this idea.
Spike or steel thread. Something I failed to mention is that you should be prepared to do this in the messiest possible way. Manual steps are just fine. The first time.
In addition to the mess, there also should be an expectation that some parts are going to be thrown out. That is, some work will need to be thrown out and re-done.
To play devil’s advocate, I would say that there is nothing that is more permanent than a temporary solution. In other words, the prototype that you/team meant to rewrite/throw away may become de-facto standard, because (1) it does the job already, and (2) priorities changed and all of the people need to jump on something else...
Permanent temporary solutions don't bother me any more. There's always a fantasy world where everything is perfectly designed, but that project's dead because it failed to deliver in time. The best of all actually possible worlds is the one in which repair keeps up with damage.
~80% of the software cost is in maintenance. Putting together a messy solution quickly is cheap and it gets the job done and is certainly better than project death (assuming your project is actually needed). The challenge and the question is who and how is going to pay to maintenance? I have read some startup people say that maintenance is a Champaign problem... I don’t know if I believe it, because maintenance starts the day your system is in production.
I feel like we have gone a full circle and came back to the iterative development: build the end-to-end working system as fast as you can, when it starts to break under load, fix it just enough, when adding features becomes hard, refactor it just enough to enable the feature development (ensuring that the cost of refactoring is lower than the benefit that the newly enabled features will bring). So is this “just” action bias and iterative development?
Some engineers look at the process you describe & imagine how much better it could be if only they had time to design everything properly from the beginning. I gave up on that vision since it never matched reality. The times I "had the time", I overengineered the system to the point it didn't work at all. Instead, I embrace the suck & focus on gratitude for still being alive.
I know something like manual steps would be a mental blocker for me on this. Not saying it should be, just that I've cultivated a bit of an aversion to them over the years. I think that's often a good thing, but I know it would be something I'd have to consciously set aside, and probably correctly so in this case.