[HN Gopher] Ways to ship software
       ___________________________________________________________________
        
       Ways to ship software
        
       Author : notoriousarun
       Score  : 41 points
       Date   : 2021-07-03 11:01 UTC (1 days ago)
        
 (HTM) web link (review.firstround.com)
 (TXT) w3m dump (review.firstround.com)
        
       | Swizec wrote:
       | 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 wrote:
         | > 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 wrote:
           | 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 wrote:
           | Why slowly?
        
       | dirtyaura wrote:
       | 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 wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2021-07-04 23:00 UTC)