Hidden costs of constantly shipping new things
mindtheproduct.com
Hidden costs of constantly shipping new things
1–10 of 62 posts
Re: Hidden costs of constantly shipping new things
#2Re: Hidden costs of constantly shipping new things
#3https://en.wikipedia.org/wiki/Feature_creep https://en.wikipedia.org/wiki/Scope_creep
That's not a particularly good way to encourage discussion.
What is it specifically about Feature & Scope creep that you would like to say?
Re: Hidden costs of constantly shipping new things
#4This is kind of interesting but it sounds like the perpetual worry of the perfectionist developer. Of course you end up with tech tech, you develop new things when you could improve existing things, you deploy something that could be iterated but you don't.
The truth is that the world is a complex place and you don't always know whether you can keep your existing customers by improving what you already have or get new customers to decrease the risk of declining income. It is hard to measure what is acceptable tech debt and what is worth addressing.
In one sense, the proof is in the income. If you can help customers with an 80% OK product then you just need to live with the dodgy 20% bit.
I agree with the danger of big customers though! If you ever think something is a way to avoid hard decisions, pivots and annoying some of your customers, then it is too good to be true ;-)
Re: Hidden costs of constantly shipping new things
#5I work at a company that grew from a few hundred to a few thousand people in a few years' time, and there was an identical mindset and identical problems over that growth period. I started during that growth period, and 10 years later, we're still digging ourselves out of those mistakes.
One reason for this was how heavily we prioritized first mover advantage. We pushed extremely hard to get into new markets, and while strategically this worked out extremely well for us, it meant that later development was hamstrung by earlier decisions. Any iteration on old features almost always meant rebuilding it entirely, and we've only just started to get to a place where previous efforts to do this are now paying off in increased velocity.
I think there's an argument that this could be good, since you're only improving features when there's some other value you can ship. However, I think it's short-sighted, because it means prioritizing small iterations has an unnecessarily large cost, simply because that cost wasn't paid down slowly over time. While I do think prioritizing new markets early on was a good call, that mindset bit us in the ass in a big way when we tried to ship a very flashy new feature later in our growth cycle that crashed and burned because of tech debt, and it took us over a year to fix everything to release it. If we had taken a mindset of building for the long term five years ago, which was already years after we'd gotten to a comfortable place in revenue and marketshare, we would probably have paid off most of the major tech debt by now.
I honestly don't know how a company can get past the addiction to shipping, at least not during its growth period. It can be strategically necessary, and I imagine in only a two-year period at the early stages of a company, like what's in this article, it's impossible to avoid. But leaders must have in the back of their heads the idea that they will need to start tipping the scales toward standardization, building to last, and building infrastructure as well as features sooner than they'd probably like to avoid larger problems in the future. And I suspect the only way leaders will really take that seriously is if they've gone through it before.
EDIT: Clarified a few points.
Re: Hidden costs of constantly shipping new things
#6What an awful article. Expensive conclusions are drawn with no apparent consideration for their cost. The experience of a company which appears to have successfully balanced complicated tradeoffs in choosing features is discounted because there were bugs. And almost no examples or useful stories about any detail, or suggestions on how to do it better other than to go (much) slower and to spend (much) more or to not take rich customers money.
I suspect good arguments could be made for these things, but they need to acknowledge and justify their cost.
Re: Hidden costs of constantly shipping new things
#7[deleted]
Re: Hidden costs of constantly shipping new things
#8Oh good, I was afraid this was going to be an intervention for me regarding my steady stream of almost daily deliveries from Amazon/HD/Walmart/Ebay etc.
Re: Hidden costs of constantly shipping new things
#9Every company suffers under the weight of the debt of being feature focused. That's because everyone who didn't do that isn't alive to tell the tale.
Re: Hidden costs of constantly shipping new things
#10I work at a company that grew from a few hundred to a few thousand people in a few years' time, and there was an identical mindset and identical problems over that growth period. I started during that growth period, and 10 years later, we're still digging ourselves out of those mistakes. One reason for this was how heavily we prioritized first mover advantage. We pushed extremely hard to get into new markets, and whi…
Apart from the one catastrophic failure you mention it sounds like, from a business perspective this worked? You were able to extend your tech debt long enough to start generating money and are now in a position to pay it back. From an engineering perspective I agree it's a grind to pay all this back and lose so much velocity. Are their business strategies that favour slower more careful engineering practises? mission-critical systems come to mind but maybe also nth-movers could be put in there? Where you know what you're building and competing with but want to make the best version of X.