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

51–60 of 62 posts

Re: Hidden costs of constantly shipping new things

#51

Post by nicoburns »

LanguageGamer wrote: post #28
codemac wrote: post #26

Earlier quoted context omitted.

> Are their business strategies that favour slower more careful engineering practises? This is a false dichotomy, and there is plenty of research (and experience) that shows shipping higher quality software actually takes less time and money.

I want to believe this. Do you have any citations? My experience would suggest shipping higher quality software is a lot cheaper in the long run, but has up-front costs that often times startups can't afford.

My companies first 5 hires were junior developers. This cost a fair packets (because there were 5 of them!) and led to pretty low quality software (because they were all junior and didn't know what they were doing).

They could have shipped higher quality software quicker by hiring 2 senior developers for similar cost.

Re: Hidden costs of constantly shipping new things

#52

Post by Slartie »

pyromine wrote: post #50
Slartie wrote: post #49

I always wonder why nobody appears to try a hybrid model between product and project development when it comes to satisfying large customers which need very specific customizations that often don't fit well into a product development roadmap aiming at satisfying a more generic audience. Like: don't just add weird features that make sense for just one customer, but are eventually delivered to all customers, but instea…

I mean you're describing what most Enterprise Resource Planning deployments look like. There's a lot of enterprise software that follows this model

You are right; probably I have to state the question in a more precise way, which would be: why is it such that this model seems only to be used in huge "enterprisey" contexts? The model of course depends on a certain modularity of the software in question, but hasn't that been a core concept not just for the biggest players, but also the smaller shops for a while now?

Re: Hidden costs of constantly shipping new things

#53

Post by RandoHolmes »

digitallogic wrote: post #43

Interesting! I especially enjoyed the insight into the evolution of the company. Though with this insight I have slightly different conclusions than the author: 1. A bias to ship and a bias to ship new things are not one and the same. A lot of the problems, such as a failure to iterate on existing products/feature, sound very much a product of the later, not the former. If anything, the issue "Insufficient Iteration"…

I think the problem is that the leaders in the company (technical or otherwise) didn't recognize that software systems are like children: They have phases.

The ship it constantly is probably ok when you're small, but at some point you need to become more mature than that, both as an organization, and as an approach to the software itself.

Re: Hidden costs of constantly shipping new things

#54

Post by RandoHolmes »

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…

> 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.

I've seen so many developers over the years who view having to rewrite that module because it can't scale well enough anymore as a failure, but I call it a success. Software is meant to be tumultuous, things SHOULD be getting replaced.

In another post in this thread I mentioned that software systems are like children in that they have phases. Assuming that your company and software team is dedicated to fixing those issues (slowly, beside new features), then I think you're probably in a healthy spot despite the pain.

An observation is that business interests must ALWAYS trump technical interests when those business interests are critical. No business = no technical. But at some point when the company becomes stable that balance has to start shifting back towards the technical or the company itself becomes ridiculously inefficient.

Re: Hidden costs of constantly shipping new things

#55

Post by RandoHolmes »

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…

> 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.

While that's probably true, it's a difficult balance to know when exactly you should start moving back towards the better development practices. Too soon and you die, too late and you can no longer move because you're too inefficient.

Re: Hidden costs of constantly shipping new things

#56

Post by macjohnmcc »

ryandrake wrote: post #48
drspacemonkey wrote: post #44

Earlier quoted context omitted.

I've had the exact same experience. Throw in a large dose of "no repeat customers" due to us prioritizing Feature A for Potential Customer B over fixing existing gaps that affected actual customers, and it was a never-ending parade of haphazardly created, bug-riddled new features that never got improved. Made every single day a death march and a company that survives purely on the sunk cost fallacy on the part of the…

Yup, and the requesting "customer" always convinces your CEO with the same argument: "Just add this feature, sell it to us, then it's part of your product forever and you can sell it to many other customers! We're paying for your NRE!" and CEO falls for it!

The company I worked for didn't even need that incentive just the potential to make a sale! We added features just to complete bullet points on a marketing sheet even if we never made a sale of the feature.

Re: Hidden costs of constantly shipping new things

#57

Post by dane-pgp »

wastedhours wrote: post #23
OliverGilan wrote: post #19

Earlier quoted context omitted.

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

At my old company we had an innovation consultant come in and tell us that kind of approach was nearly impossible to manage in the longer term. Apparently teams dedicated to holding the fort grew bitter and had much lower retention than teams on greenfield work. Paying back the debt, he said, usually requires too much knowledge of a system to cycle teams in and out consistently enough to ensure everyone gets a piece…

> Apparently teams dedicated to holding the fort grew bitter and had much lower retention

As someone who found themself in the "holding the fort" team, I can confirm that this analysis is at least anecdotally true, although the terms I preferred at the time for the two teams were Morlocks and Eloi.

Re: Hidden costs of constantly shipping new things

#58

Post by trentnix »

There's a lot of insight packed into this post, and really it transcends way beyond the mindset of constantly shipping new things. This particular line resonated with me:

Big customers certainly sounded good on paper, but they came with a cost (complexity and a very hands-on relationship) that we weren’t really prepared for, and that we didn’t manage to put boundaries on fast enough.

This is an issue I've dealt with more than once in my career. It seems to occur especially when an organization values the sale more than it values the business. It's virtually impossible to successfully apply boundaries after the customer has been trained that there are none. Irrespective of how carefully you do it or how much you try to reassure your customer, it always feels like you are taking value away. I've encountered this recently in an organization that values customer happiness, which it calculates as an absence of customer complaints, more than customer success. The squeaky wheels get all the grease at the expense of just about everything else.

And the software inevitably has become a maze of settings and IF-THEN-ELSE blocks and SWITCH statements, increasing the cognitive load required to make what should be simple changes. When new features are added, the impulse is to code defensively and build inevitable customization into everything up front. And further down the spiral of technical debt and increasing complexity we go...

Re: Hidden costs of constantly shipping new things

#59

Post by rahimnathwani »

Slartie wrote: post #52
pyromine wrote: post #50

Earlier quoted context omitted.

I mean you're describing what most Enterprise Resource Planning deployments look like. There's a lot of enterprise software that follows this model

You are right; probably I have to state the question in a more precise way, which would be: why is it such that this model seems only to be used in huge "enterprisey" contexts? The model of course depends on a certain modularity of the software in question, but hasn't that been a core concept not just for the biggest players, but also the smaller shops for a while now?

Implementation costs a lot, not just in coding, but in all the extra work that goes into sales, gathering requirements, training etc. Whoever nominally pays for all that work, it translates into a high price tag for the customer. Only large enterprises will get enough value from the customisations for that high price tag to be worthwhile.

All else being equal, a smaller company will spend a lower absolute amount to work around imperfections, and get lower value from any product overall. So of course they will not be willing to pay as high a price. Hence, for commodity use cases, use commodity software rather than fully/semi-customised.

Re: Hidden costs of constantly shipping new things

#60

Post by r0ze-at-hn »

wastedhours wrote: post #23
OliverGilan wrote: post #19

Earlier quoted context omitted.

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

At my old company we had an innovation consultant come in and tell us that kind of approach was nearly impossible to manage in the longer term. Apparently teams dedicated to holding the fort grew bitter and had much lower retention than teams on greenfield work. Paying back the debt, he said, usually requires too much knowledge of a system to cycle teams in and out consistently enough to ensure everyone gets a piece…

Worse than the fact that those holding the fort would leave, the best of those would leave (either to another company or just as often to the exciting new projects) leaving behind those that can't leave and very rapidly you end up with a not that great group which management doesn't notice or deal with.
Post reply on HN