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

31–40 of 62 posts

Re: Hidden costs of constantly shipping new things

#31

Post by spaetzleesser »

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 than teams on greenfield work.“

Very true. The good performers will be “rewarded” doing the things that are really important: keeping things going. And then you have low performers and interns doing the new stuff.

Re: Hidden costs of constantly shipping new things

#32

Post by spaetzleesser »

sundbry wrote: post #27
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

Then you just end up with the first team continuing to produce garbage, and leaving it up to the 'fixers' to clean it up.

And the innovation team will have stellar resumes while the people who fix things will look like outdated dinosaurs.

Re: Hidden costs of constantly shipping new things

#33

Post by nitrogen »

spaetzleesser wrote: post #31
wastedhours wrote: post #23

Earlier quoted context omitted.

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 than teams on greenfield work.“ Very true. The good performers will be “rewarded” doing the things that are really important: keeping things going. And then you have low performers and interns doing the new stuff.

That can happen too, though I think you're saying the opposite of the parent comment.

Re: Hidden costs of constantly shipping new things

#34

Post by jamil7 »

codemac wrote: post #26
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…

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

> 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 believe you when the business knows exactly what it's building. In the context of the article and the comment I was responding to, building high quality software wouldn't have helped them early on, thats kinda the whole point of tech debt and the discussion here. Knowing when is the right time to start changing the engineering culture and how easy (or hard) it is to do that.

Re: Hidden costs of constantly shipping new things

#35

Post by sundbry »

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.

You can afford them if you don't have project managers or sales guys begging for their demoable results of new shiny thing and promising it to others too early and too often.

Re: Hidden costs of constantly shipping new things

#36

Post by troelsSteegin »

I think this is a solid critical reflection that at least in enterprise relates well.

When it comes to your customers, I believe that you want to understand as much as you can, as early as you can, about what they are actually trying to do and about how they are actually faring with what you have sold them. I'd argue that the success of your initial customers is more important than the features for your next deal, and that feature investments should reflect that.

The problem, as the OP said, is in estimating the difference between the incremental feature requirements of your initial customers and what your strategic feature set will be. There may be no difference, and your strategy is to ship features in order satisfy each new customer as you get it. Perhaps you can design for that. Chances are though that your first customers are not wholly repsentative of your strategic, target market.

So, in the early stage, you have to make choices about allocating dev for tactical "now" or for strategic "later". In the early stage, if there is not enough "now", there is no "later". The question is when to begin budget for later. I'll argue that you are attempting to build a business, not a suspense movie, and that you budget a fixed amount for "later" from day one. Plan to succeed.

I agree with the recommendation of a strong Professional Services function as an buffer for dev, but will note that culturally you have to work hard to not silo. Your Support and ProServe teams become a primary channel of learning for dev. As a business, though, you may have to give away ProServ hours.

All in all my biggest takeaway here is that you attempt to "hire" customers strategically. As you journey together, will this customer want to go where you will want to go? What time is it when your "Big Customer" sits on your roadmap? ...

"Hire" customers strategically is easier said than done when there's salaries on the line -- accordingly look at how you compensate Sales and budget away from early stage big deals.

Re: Hidden costs of constantly shipping new things

#37

Post by nitrogen »

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.

Startups bias toward hiring some less experienced developers by their nature, so they don't always know how to build quickly and solidly. The up front cost is either learning skills of abstraction from scratch, or hiring people who have.

Re: Hidden costs of constantly shipping new things

#38

Post by coredog64 »

OliverGilan wrote: post #19
montagg wrote: post #18

Earlier quoted context omitted.

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

Other people are also commenting, but IME, completely disassociating “making the think from “making the thing so that it can be supported” is a recipe for trouble.

There’s not an easy fix though, as most of the time I see orgs just punt at some point and allow the dev shop to write off all their tech debt by reassigning responsibility to an ops team.

Re: Hidden costs of constantly shipping new things

#39

Post by coredog64 »

jorblumesea wrote: post #24
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…

The core issue, from what I've seen, is one of incentives. Many leaders at many companies are compensated on growth and short term factors. It's hard to find a leader that is willing to take a 5 year look, or even find a leader that is planning on being around 5+ years. The leadership at my publicly traded company is a revolving door of short term hacks for promos followed by a quick pivot to the competition or anoth…

I would add that when it’s not a revolving door it’s frequently someone who used to be technical and still fancies themselves as an elite coder. That in turn leads to low level decisions (how and not what) being made at the top. As a result, you’re chasing “cool” rather than “best long term decision” in service of the ego of someone who is already being appropriately compensated monetarily.

Re: Hidden costs of constantly shipping new things

#40

Post by satyrnein »

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…

My previous employer prioritized shipping, won the market while having both more features and more technical debt than competitors, bought those competitors out as they started failing, and then migrated their clients over and threw their beautiful (but less featured) systems right into the garbage. To this day, I sometimes think back to how a particular competitor had the right schema for solving current problems, but they didn't even survive to the current day, which takes precedence.
Post reply on HN