Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not ship work in progress: An open letter

dont-ship.it

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Do not ship work in progress: An open letter

#71

Post by scrame »

rob74 wrote: post #6
kop316 wrote: post #4

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 > Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken v…

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

Is there any dev methodology that doesn't get bogged down by process?

Re: Do not ship work in progress: An open letter

#72

Post by RunningDroid »

rob74 wrote: post #6
kop316 wrote: post #4

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 > Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken v…

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

> Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

Void Linux

Re: Do not ship work in progress: An open letter

#73

Post by lopkeny12ko »

purpleblue wrote: post #62

I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable, ie. midway through feature development. I vehemently pushed back, saying that it would be disruptive to our customers since the feature wasn't fully finished and it would slow us down, because we would need to change the order in which we would do development since custome…

What does this anecdote have anything to do with the article?

Re: Do not ship work in progress: An open letter

#74

Post by [deleted] »

WesolyKubeczek wrote: post #15

But then again, free and open source licenses enable everyone to do any modifications for any purpose whatsoever. That's the whole point. I would like it if the developers quit being patronizing towards people exercising their rights under those licenses. Yes, don't ship it, don't theme my app. We all heard you. Some people choose to not care, and that's okay. Those same licenses also disclaim any warranty, so the bu…

[deleted]

Re: Do not ship work in progress: An open letter

#75

Post by donmaq »

purpleblue wrote: post #62

I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable, ie. midway through feature development. I vehemently pushed back, saying that it would be disruptive to our customers since the feature wasn't fully finished and it would slow us down, because we would need to change the order in which we would do development since custome…

> I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable

FWIW, I recognize it's fun to target PMs for ignoring technical constraints & carrying water for marketing... but for many PMs (in USA at least), they roll up to Marketing dept, rather than Eng.

So while it can seem PMs are (willfully?) technically Invincibly ignorant by default, their bosses are worse.

The best way to 'manage' your PM is help them build the biz case for your position. Eg "reduce risk of $XX loss" from bugs, opty costs, network effects of customer losing faith in your product. Plus I've found the "walk before you can run" argument works: they want to expand customer excitement by showing bright/shiny/new things. Promise them an even faster cadence of new things, after they give you time to get the fundamentals deployed.

Re: Do not ship work in progress: An open letter

#76

Post by immibis »

WesolyKubeczek wrote: post #60
simiones wrote: post #23

Earlier quoted context omitted.

The problem is something like this: you develop packageA. A user of distroB is installing pacakgeA from distroB latest, and packageA is not working for them. distroB maintainers tell them to go ask packageA about the bug. So, the user comes and bothers packageA about this issue - even though packageA had no intention of distributing this in-progress version to users. Now, of course, no one here is doing anything ille…

If a user comes to me bothering me about some package some distro made of my software, I show the part that says NO WARRANTY and AS IS, and get on with my life. Also, why should it “bother” anyone at all. You duke it out with whoever brought it to you. It’s only a problem if you feel a need to please everyone knocking on your doors, which inevitably turns into burnout and you actually behaving harshly towards everyon…

So your response to bug reports is to ignore them and tell the reporter to F off?

Re: Do not ship work in progress: An open letter

#77

Post by antonvs »

systemvoltage wrote: post #64
eastbound wrote: post #39

Earlier quoted context omitted.

“If you’re not ashamed of your first version, you shipped too late.” Reid Hoffman

This is bullshit. There is a big difference between: 1) Shipping low features but high quality SaaS aap: OK 2) Shipping low quality services with lots of features that are buggy: NOT OK From a customer standpoint, I reject half-baked SaaS services that reek with lack of quality control. If you are ashamed of your first version because of bugs, stop and fix those. If you're ashamed of how minimal your first app is? Th…

Spoken like a developer, not a businessperson.

The real world is a lot more complicated. As Rumsfeld put it, "You go to war with the army you have, not the army you might want or wish to have at a later time."

A startup might have a product with a promising and unique core feature, but still have many other features that are buggy. It's common for startups to be overambitious, and that often manifests as buggy features.

Startups like this will often have a high churn rate with early customers and trials. But that changes over time as they get experience with which features and which issues matter.

If you want to kill a new business quickly, "stop and fix" the bugs in your first version. The problem is, your first version may very well not be the one with the best product/market fit, and you just wasted your precious investment money, time, and resources fixing bugs that ultimately won't matter.

Re: Do not ship work in progress: An open letter

#78

Post by natch »

pessimizer wrote: post #61
natch wrote: post #45

Earlier quoted context omitted.

I wouldn’t say it addresses it so much as it acknowledges it as an issue without offering a workable solution.

What's a more workable solution for urgent patches than not including them in the request to "not ship work in progress."

If the developers themselves don’t “ship” changes to any copy of their repository outside of their own privately accessible space, the (perceived from their perspective) problem is solved.
Post reply on HN