Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hidden costs of constantly shipping new things

mindtheproduct.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: Hidden costs of constantly shipping new things

#11

Post by michalbugno »

pkteison wrote: post #6

What 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 t…

Author here. Sorry you didn't like it :)

It's tough to suggest detailed solutions to a problem which is in general very vague. Btw I hope the article shows my appreciation for what the company achieved.

One small insight from Uzi (CEO + founder) when I discussed this with him (after publishing article): Base should've focused on much less features but with greater detail. It somehow confirms my guess that we didn't work on existing features as much as we should, but we "spread too thin".

Re: Hidden costs of constantly shipping new things

#12

Post by at-fates-hands »

lbriner wrote: post #4

This 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 ne…

I worked at a large web development company. The one thing which continually hamstrung the company was we had several large customers who were paying us a good chunk of money to maintain their web properties. They sucked up so much of our resources to keep them happy that other smaller customers suffered as a result.

The amount of churn we had was always the smaller clients who were still paying good money but felt neglected and would be open to changing vendors.

We went out of our way to mind the big clients and thought if we lost these few big clients it would so dramatically adverse the companies bottom line, we couldn't afford to lose them. This resulted in a situation where they were able to hold our company hostage, make unreasonable demands on time and energy and hamstrung our ability to keep our more loyal clients (who only bothered us on occasion) happy.

It was a good lesson there is a danger when you have a small company servicing a much larger company that you get into a position where your fear of losing them is a detriment to your other, more faithful clients.

Re: Hidden costs of constantly shipping new things

#13

Post by mlyle »

jamil7 wrote: post #10
montagg wrote: post #5

I 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? missio…

I think that they're saying, in retrospect, they could have started making some payments on the debt a bit earlier when the business had scale and sustainability. And that in turn this would have avoided a lot of unpleasantness.

It's hard to change culture; you tend to keep doing what worked before even if it's not optimal anymore. Yesterday's adaptive behavior is today's unfortunate practice.

Re: Hidden costs of constantly shipping new things

#14

Post by michalbugno »

lbriner wrote: post #4

This 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 ne…

I'm far from being a developer perfectionist, I wouldn't spend 10 years in this company if I was one, trust me (btw we fired a lot of them along the way).

The point of the article is not to convince anyone to slow down as much as possible and work on bugs/etc. It's just that at some point (3, 4 years in?) there comes a time that you just have to put more effort into the things I described, otherwise it gets complicated fast.

Obviously there is a tradeoff, my opinion is that this tradeoff wasn't correctly balanced (especially further down).

Re: Hidden costs of constantly shipping new things

#16

Post by jamil7 »

mlyle wrote: post #13
jamil7 wrote: post #10

Earlier quoted context omitted.

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? missio…

I think that they're saying, in retrospect, they could have started making some payments on the debt a bit earlier when the business had scale and sustainability. And that in turn this would have avoided a lot of unpleasantness. It's hard to change culture; you tend to keep doing what worked before even if it's not optimal anymore. Yesterday's adaptive behavior is today's unfortunate practice.

Yeah OK that makes sense.

Re: Hidden costs of constantly shipping new things

#18

Post by montagg »

jamil7 wrote: post #10
montagg wrote: post #5

I 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? missio…

Well, yes, I am saying from a business perspective this worked. but I also think we got lucky. Around five years ago, a little before the high profile failure, we were starting to lose marketshare, and though we've been able to claw most of it back, I think it's far more due to missteps of our competitors than our own performance. Had we invested in more sustainable development earlier, I think we would have been able to move faster to take advantage of new opportunities, diversify our revenue streams earlier (adding to them now is hamstrung in large part because of tech debt), and head off competitors faster.

In fact, once we started investing in that kind of development, we did do that with a successful new feature that we developed much more quickly than we could have in the past, and it's because of that success that leaders are finally starting to prioritize building standardized and reusable infrastructure.

EDIT: I think another way to say this is, once we knew our strengths and how we'd be successful in the future, we should have operationalized that and hardened it, so we'd have a sustainable advantage over competitors. Instead, we kept the "move fast, be flexible, and throw man-hours at problems" mentality too long, and it put us at risk.

Re: Hidden costs of constantly shipping new things

#19

Post by OliverGilan »

montagg wrote: post #18
jamil7 wrote: post #10

Earlier quoted context omitted.

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? missio…

Well, yes, I am saying from a business perspective this worked. but I also think we got lucky. Around five years ago, a little before the high profile failure, we were starting to lose marketshare, and though we've been able to claw most of it back, I think it's far more due to missteps of our competitors than our own performance. Had we invested in more sustainable development earlier, I think we would have been abl…

Could there be a hybrid approach? Have teams that focus on being a first mover and shipping and then once there's a product on the market, you have a secondary team focusing on fixing the tech debt early while the other team continues to iterate

Re: Hidden costs of constantly shipping new things

#20

Post by michalbugno »

hn_throwaway_99 wrote: post #17

Also could be titled "Hidden costs of moving to microservices because the cool kids are." Very glad (most of) the cool kids have re-evaluated their stance on microservices.

I have a plan to write a short article about specifically this topic at Base. I personally fucked up a ton of things with microservices there :)
Post reply on HN