4 ms·

Ways to ship software

107 points by notoriousarun 5y ago

dirtyaura 5y ago
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.
- Mertax 5y ago
  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.
Swizec 5y ago
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.
- Zababa 5y ago
  > 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?
  - Swizec 5y ago
    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.
  - robotresearcher 5y ago
    Why slowly?
    - jerrre 5y ago
      Might be because it's hard to reverse such a process if needed?
- catwind7 5y ago
  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.
- nly 5y ago
  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.
- allenleein 5y ago
catwind7 5y ago
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.
george152 5y ago
I'm constantly searching on the internet for posts that will help me. https://www.omegle.vin/ https://www.omegle.vin/

107 points by notoriousarun 5y ago

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.

Mertax 5y ago
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.

Swizec 5y ago

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.

Zababa 5y ago
> 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?
- Swizec 5y ago
  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.
- robotresearcher 5y ago
  Why slowly?
  - jerrre 5y ago
    Might be because it's hard to reverse such a process if needed?
catwind7 5y ago
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.
nly 5y ago
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.
allenleein 5y ago

catwind7 5y ago

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.

george152 5y ago

I'm constantly searching on the internet for posts that will help me. https://www.omegle.vin/ https://www.omegle.vin/