3 ms·
This is advice that has always sounded good to me on paper but not quite right in practice. Scaffolding is great, until it isn't. It needs to be replaced with
by hinkley 1y ago
This is advice that has always sounded good to me on paper but not quite right in practice.
Scaffolding is great, until it isn't. It needs to be replaced with something resembling a Real Solution before the Last Responsible Moment comes and goes. But due to Hofstadter's Law as well as Queuing Theory, we can never get the timing right.
And so a lot of the devs you encounter who fight this have found themselves spending a lot of time throwing good money after bad, keeping a broken system working just enough that the customers don't defect, while trying to also find the time to replace the broken system, which is also always being made more difficult by the changes being made to keep the busted shit kinda working.
And so at some point they just say Enough. I'm not going to lie to myself and my coworkers by saying "We'll fix that later" because "later" never comes, only "too late" comes.
There are ways to spin this however. If the customer trusts that you know what you're doing and that you will eventually get to all of their problems, they'll stay put while you work on them. But you have to telegraph competence and then deliver on it. There's a needle you can thread there where you use not shipping systems that Don't Scale... ridiculously badly, you can tell the users to expect quality.
I will say this, as a compromise: It is almost always better to ship systems that scale too expensively than ones that don't scale at all - as long as that scaling leads directly to revenue. You're only shortening your runway by decreasing margins or taking them narrow. But if your customer base plateaus because you just can't onboard them anymore, what investor is going to float you more money to extend that runway?
I have always found it easier to negotiate priority on feature and story work that's attached to a new revenue stream (eg, new account) than ones that only reduce our OPEX. When the checks clear, a small but statistically significant amount of 'generosity' flows. You have to be ready though when it happens because the window is short.
Hey if we're going to land that Fortune 500 company, we need to work on ??? because they're likely to notice it sucks, if they don't just knock it over entirely in six months.
- ipnon 1y agoI think it's right in practice. Your first users are the kind of people who need something new and don't care if it's unscaled. They just need the new solution. You have to find the 1 person who needs the new thing you have, and it's the greatest filter stage for startups. Any time spent optimizing for the next 10 or 100 users is time spent wasted against looking for that 1 person.