Ways to ship software | Hacker News Reader

Ways to ship software

review.firstround.com

107 pointsnotoriousarun11 comments

After a few years in startups, I’ve found the only death knell to shipping software – when product runs out of ideas.

You can work around everything else. Prioritize speed or stability, use different standards for different areas, even any number of project management methodologies. A group of talented folks with a goal can make anything work.

But when you’re out of ideas, that’s when shipping dies. Your engineering department devolves into a pile of factorings and refactorings and turd polishing projects and academic exercises and none of it drives the business forward. It’s just busywork because engineers are expensive.

And trust me, they’re gonna get tired of the busywork and they will leave. You’ll get tired of paying them for busywork too.

> when product runs out of ideas

Could this mean that the product is "finished" and you can put it in support mode and slowly reduce the number of people working on it?

That may be, but it doesn’t jive with the VC monkey strapped to your back. It usually means there isn’t enough user interest/engagement.

Users always have problems they run into or novel usecases they’d like to use you for.

Why slowly?

Might be because it's hard to reverse such a process if needed?

what if you have plenty of ideas but you run out of money because you can't ship fast enough? :D sorry couldn't help it

on more serious note - I'm curious what you mean by run out of ideas. do you mean product literally not having any ideas? that seems hard to believe. Or do you mean ideas just don't gain traction? I've seen that happen a lot more.

I've worked for a small business that had no end of ideas, and had the money and the talent to execute. These days it's still profitable despite the fact that the product look largely unchanged from 5 years ago. Competition moving in on the product is seen as "making the overall pie bigger".

A failure to grow doesn't necessarily mean business failure. Sometimes business owners just want a lifestyle business.

This is so true. I worked at a startup backed by famous VCs. We over-raised seed $, hired some top engineers to work on a VCish product with different cool dev methodologies.

Two years later, the ship went down. If I were the founder, I would focus on one thing: ship something people want badly as fast as possible.

An excellent piece. I’m especially interested to hear stories from the fellow HNers about the last point Jocelyn mentions: how to build 2 shipping cultures inside one company, when your business requires it (for example: two-sided marketplaces with different apps for consumer and businesses).

In our case, we have this situation with SW vs HW shipping culture. On the SW side, we focus on continuously developing features and have deliberately emphasized productivity over schedule-predictability, while on the HW side they naturally are focused more on schedule-predictability due to complex dependencies.

Now, this dichotomy has created an interesting discussions inside the company on the right way to ship products and projects, and to me, arguments mainly come from the fact that people come from the different shipping culture and have hard time to see the benefits and requirements of the other culture.

I also come from a company that ships both HW & SW products. Our HW roots are much deeper than our SW roots and HW shipping mentalities have mostly prevailed (low risk tolerance, waterfall development, strict schedule).

Where we’ve had success is identifying the difference between SW that supports the hardware vs independent SW products that compliment the HW, and choosing to ship those products with different processes. Basically if the SW can support a recurring revenue model it follows a continuous development process. But if the software is really just the “operating system” for the hardware then it ships very much the way the rest of HW ships.

I really like how she connects the necessity of the software for customers to release risk management. It's a very user-centric view which I like. Helps me understand release processes I've experienced much better from a business angle too. It makes sense that with few vendors who will experience high degrees of pain from bad releases that it tends to encourage more conservative, move-slow-and-don't-break-shit mentality.

Reply on news.ycombinator.com