Live data from Hacker News

The Last 1%

jaredramsey.com

41–50 of 93 posts

Re: The Last 1%

#41

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.

Re: The Last 1%

#42
Those don't sound like 1%. They sound like a lot more than that. Which is why they don't get done. Who has the time?

Re: The Last 1%

#43

None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to b…

> They're all a form of technical debt that should be used very sparingly

I'm not sure if you mean you should hardly ever, or almost always, do the "1%" things.

Re: The Last 1%

#45

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.

In todays age sure, But just looking back at games pre monetization / MBA era, they still work. Sure there are some bugs/ glitches/ but not much that breaks the game.

You can pretty much play any game pre PS3 era still enjoy it to it's fullest.

Re: The Last 1%

#46
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, usually several.

Since we're being pedantic, plenty of software projects that have made their owners many millions of dollars have subsequently failed. Who uses WordPerfect or Lotus 1-2-3?

Re: The Last 1%

#47
post #45

Earlier quoted context omitted.

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.

In todays age sure, But just looking back at games pre monetization / MBA era, they still work. Sure there are some bugs/ glitches/ but not much that breaks the game. You can pretty much play any game pre PS3 era still enjoy it to it's fullest.

Similarly there’s the feeling of DONE for games of that era. Burn that Gold Master, or mask those cartridge ROMs, and it’s done. Fini.

Whatever shenanigans were done late in the project, if it passed QA, that code base was effectively read only, with little concern for ongoing maintenance.

On to the next one.

Re: The Last 1%

#48

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…

I think this is the difference between products and projects. Projects definitely have an end. Products do not.

Re: The Last 1%

#49
post #8

All of those things should be added. I would argue they take far more than 1%. They're easily 10, 20 maybe 30 or 40% of the work. Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends when done but often gets thrown out because we schedule our work for 'MVP and yeet' where 'minimum' is de…

Having worked in multiple environments with differing code quality standards, it's pretty apparent how both "minimum and yeet" and "completion or bust" fail. "Minimum and yeet" works surprisingly well if you have unsolvable debates on customer value, options to yank the feature if it sucks, and generally competent engineers. If you are really good at yanking the feature when it sucks - you may even be able to get awa…

What do you mean by this? > In an ideal world, I'd love to see organizations better adapt their standards to the needs of individual teams or invest in tooling which makes it "cheap" to do the right thing. However this is not easy to pull off.

What does that look like in practice?

Re: The Last 1%

#50

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.

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" software release and be just fine (at least up until recently before the whole "everything needs to have internet for telemetry" hype).

Post reply on HN