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.
This makes sense. In that case the summary of your note for me is to focus on end-to-end completion first to prove/verify the benefit of the system... or else the system/project/startup will just die. Am I getting this right?
In practice, unfortunately, I have seen lofty-sounding visions work better for getting headcount and/or promotions (at least at large companies). “Wouldn’t you want this system with amazing capabilities? It will do everything you want and more. Well, we have made a lot of progress (look at the volume of code we wrote!) if only we had more people etc we could complete it sooner...”. On the other hand, if you build and ship something, your boss may hear about problems and issues that system is causing and all the imperfections that is has... and you are left motorboating: “but ... but... but... our system makes / saves millions of dollars...” but since this isn’t your boss’s money anyway (and bring a large cost center has benefits!) it may not be a winning strategy.
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.
This makes sense. In that case the summary of your note for me is to focus on end-to-end completion first to prove/verify the benefit of the system... or else the system/project/startup will just die. Am I getting this right?
In practice, unfortunately, I have seen lofty-sounding visions work better for getting headcount and/or promotions (at least at large companies). “Wouldn’t you want this system with amazing capabilities? It will do everything you want and more. Well, we have made a lot of progress (look at the volume of code we wrote!) if only we had more people etc we could complete it sooner...”. On the other hand, if you build and ship something, your boss may hear about problems and issues that system is causing and all the imperfections that is has... and you are left motorboating: “but ... but... but... our system makes / saves millions of dollars...” but since this isn’t your boss’s money anyway (and bring a large cost center has benefits!) it may not be a winning strategy.
No question--the incentives are not aligned. That's why I frequently say, "With my investor hat on..."
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.