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

The Last 1%

jaredramsey.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: The Last 1%

#71

Post by lazyasciiart »

User23 wrote: post #46
pc86 wrote: post #37

The article is, on its face, completely wrong. > This last 1% [is] what separates a product that might not eventually fail from one that will eventually fail. Then proceeds to list a dozen different types of instrumentation, dashboards, and documentation. I don't know about anyone else here but I've working on many, many successful software projects that have made their owners many millions of dollars with out-of-dat…

> I don't know about anyone else here but I've working on many, many successful software projects that have made their owners many millions of dollars with out-of-date or missing documentation, minimal instrumentation, and minimal or no dashboards to speak of. Most projects I've worked on have achieved at least some level of commercial success and the vast majority missed at least one of those major categories, usual…

And no automation or performance dashboards would have made them “not eventually fail”. (Among other reasons - I like how this article just assumes your product is Saas)

Re: The Last 1%

#72

Post by noduerme »

angarg12 wrote: post #35

I think the whole premise of this article is wrong. If a project is successful, it isn't 99% done; essentially it will never be done so long it is alive, supported, and/or used by anyone (I won't get into semantics here). As others have pointed out, many of those things should be done way earlier as part of the development, AND as part of the ongoing development/maintenance after launch. On another note I'm also skep…

Another way of looking at it: Nothing is ever 100% done when it launches. Nor should you wait for it to be, if it's been tested to your own complete satisfaction. I frequently launch things over 3-4 different beta phases to increasingly large swaths of customers, while documentation is still being hashed out by staff who are coming up to speed on the feature themselves. My goal is that at the 1-year mark, more or less, there are almost no bugs, by which time I've forgotten the nuts and bolts of the code. Meanwhile there are other features and pieces of software that need building.

Re: The Last 1%

#73

Post by noduerme »

jrochkind1 wrote: post #41
angarg12 wrote: post #35

I think the whole premise of this article is wrong. If a project is successful, it isn't 99% done; essentially it will never be done so long it is alive, supported, and/or used by anyone (I won't get into semantics here). As others have pointed out, many of those things should be done way earlier as part of the development, AND as part of the ongoing development/maintenance after launch. On another note I'm also skep…

Good call. Software is a living organism, or it is dying. Just as a practical observed matter of how it actually works out. There are a few exceptions, but few indeed.

Kind of? But only because of forced upgrades.

The best code I've written is the code that's still running 15+ years later and no one even thinks about.

Re: The Last 1%

#74

Post by Nevermark »

I would suggest doing the last 1% first, but therein lies an infinite regress.

More practical: have a well defined checklist of must-do's. And a separate list of significant nice-to-do's.

Then wind up a project any time all must-do's are done, with however many nice-to-do's actually got done.

So the last 1% (10%? 25%) are optional nice-to-do's that can be scaled back without concern. The optionality of nice-to-do's pads schedules, making targets dates easier to hit.

Re: The Last 1%

#76

Post by coldtea »

hackernewds wrote: post #65
coldtea wrote: post #22

> So what's in this last 1%? Here are some of the most frequently skipped things I've seen: Internal (maintenance) documentation External (how-to/FAQ) documentation Performance metric instrumentation Easy-to-decipher performance metric dashboard Usage metric instrumentation Easy-to-decipher usage metric dashboard Error metric instrumentation Easy-to-decipher error metric dashboard Alerting Automated testing None of t…

> None of the above are even important in launching a product, much less an MVP. Hence an MVP is a MINIMUM viable product > Startups have raised hundreds of millions and get millions of users without any of those A very narrow definition of what makes a good product or long term enduring company. Unless all we should care about is VCs and founder exit sales

>Hence an MVP is a MINIMUM viable product

Mimimum public features-wise. Not minimum because it doesn't have a performance dashboard, alerting, and automated testing.

>A very narrow definition of what makes a good product or long term enduring company.

None of the things listed are essential for "a good product".

Re: The Last 1%

#78

Post by rustybolt »

That last 1% sounds like a godawful lot of work. With this attitude, you can never call something "done", and I deeply hate this notion of "things that are never finished". Like "you are never done learning C++". It implies that everything you do will haunt you for the rest of your life, that everything you do is a liability, and that there is some moral code or obligation to developers to do things because it is convenient to other people.

This, together with the ever-increasing complexity of well, everything, and the increasing number of "things developers should know about X", together with the notion that developers should always work fulltime and learn in their own free time, is non-sustainable.

It's a painful fact that in this "modern" environment, we just can't build anything anymore. There have been three critical vulnerabilities just today (Downfall, TunnelCrack, Inception). If you make a website it's probably hundreds of kilobytes big and you get people whining over accessibility and how it breaks dark mode of version 23.42.23 of their obscure browser.

Have you ever noticed how productive people like Fabrice Bellard just don't care about that stuff? The last procent is just a trap to suck you into the tarpit of spending time on useless shit. Choose a stable target and reasonable feature set, release, and never touch your project again. Bliss.

Re: The Last 1%

#79

Post by sethammons »

gorenb wrote: post #63

I don’t think it’s very likely that a developer will ever implement automated testing.

I'm a developer and I require automated testing even on my personal projects. Every change I make, I _know_ it will not fundamentally break for my users. I never manually run through to check things before release, tests cover it. (Yes bugs happen; that is different than releasing code that can't talk to the database because you can't be bothered to check that the app works at all)

If you are not pushing for automated tests from the start on a project that will be released to users, I think you have some professional maturing to do. It can be small and simple but it must exist.

Re: The Last 1%

#80

Post by mjlangiii »

huganabaga wrote: post #52
bboygravity wrote: post #50

Earlier quoted context omitted.

Firmware is also software and as far as I can estimate it never got updated after release in the vast majority of cases up until like a decade ago. Think BIOS/vacuum cleaner/shaver/toothbrush/alarm clock/dumbphone/non-smart TV/airplane kitchen equipment/medical diagnostics devices/PLC's that control most of the entire world's infrastructure and so on. It's entirely possible and very common to have an actual "final" s…

And that's a problem. Often there are full of issues which eventually are all known but never fixed. Updateability is the defining advantage of software over pure hardware solutions. If you don't use the advantage then you are stuck with just all the disadvantages.

Nice theory, but it is overfitted to a broad category of all software and a product that is thriving shouldn't be conflated with a product that is improving.

Some products with software continue to "live on" successfully and thrive, without updates. Think of a digital alarm clock who's goal was to help typical users to wake up on time most of the time. If you ship a product that does that and it isn't being updated, is the product really dying or doomed to failure?

No alarm clock will ever wake everyone up on time, but we can always strive to get closer to that goal if we chose to set that goal. An unreasonable goal could cause unnecessary bike shedding, etc.

But a simple pacemaker for the heart, the goal is closer to the idea of helping as many people as possible, rather than most. Hopefully we write good software and we go 15 years without needing an update. I think that is better than bad software that has to receive more updates. Which software is more "alive" and "thriving". Is the good software with no updates for 15 years really "dying" since it isn't "improving"? Again, thriving and improving shouldn't be conflated.

So, a product setting appropriate goals helps determine how much maintenance is actually necessary and some goals can be met without requiring any future maintenance. Other goals may benefit from frequent maintenance. Some products can thrive without improving. A product's goals determine's the importance of improvements.

Post reply on HN