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

31–40 of 93 posts

Re: The Last 1%

#31

Post by cableshaft »

freetanga wrote: post #21
xyzzy4747 wrote: post #12

If something isn’t making for example the cost of a fulltime salary in revenue then the last 1% is a waste of time.

Until something undocumented, unmonitored or untested fully collapses and then you loose potential revenue or harm the brand and company market cap. Revenue is not the only metric to consider IMHO.

Sure if you want to spend tons of money on a product that doesn't sell. I've seen corporations do it multiple times before (I myself was staffed on a project that was going to be 'the future of our department', worked on an MVP for almost six months, then the project was shuttered when the two major clients they were planning to sell it to didn't end up signing the contract in the end (one eventually tried to do their own in-house though, and tried to get us to just hand them our business logic for it).

If we had spent an extra four months or so getting this 'last 1%' done, it wouldn't have mattered. It would have just been even more of a waste of time and resources. At least they realized it before we polished the hell out of it.

Re: The Last 1%

#32

Post by ChrisMarshallNY »

I find that a lot of that can be added as the code is written.

I tend to use a lot of headerdoc-type of stuff, and the last documentation is often running Jazzy on my codebase, and uploading that to the "docs" directory in GitHub.

Error handling should not (IMNSHO) be put off until the end. It should be designed in from the start. We can add "do-nothing stubs," but they should still be there, for when we need to go back, and hook up the reporting.

Localization is also something that I don't think should be left out until the end. I design my code, so that every string is a placeholder token, and is replaced at build/run time. This also allows for easy integration of marketing "talking points," and a "corporate glossary." These may not be a big deal to the coders, but people who sign checks like them.

Etc.

I have a little screed on how I do documentation, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

Re: The Last 1%

#33

Post by quickthrower2 »

Do the stuff you hate as part of the project. A lot of that stuff is at least "during" and maybe best as "beginning". Write the docs first, or the landing page first, or whatever and you may even change the very feature you are working on as you realize it makes no sense.

Re: The Last 1%

#34

Post by quickthrower2 »

zwieback wrote: post #11
bluefishinit wrote: post #7

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…

Just wondering, have you ever worked on something with a longer lifetime than the typical young engineer's job rotation? One thing we run into all the time is awesome quickly iterated things outlasting many people who understand how it was done. Admittedly there's a big difference between web apps and products that are meant to last or even contain hardware components.

The differing views I reckon is Startup VS. Older business. We are now veering into "strategy". You need to think about what your "100%" looks like for a project. Lower case agile makes these 100%s smaller by the projects being smaller so you have more information for the next iteration.

Re: The Last 1%

#35

Post by angarg12 »

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 skeptical that a project should ever be 100% done even if that was possible. I had the privilege of working on a project during the whole lifecycle, including when it was deprecated and eventually decommissioned. It was very pleasant to go through all of the open Jira tickets for this product and close them as Won't Fix forever. All of those features, bugfixes and enhancements were never implemented. The project launched, lived, and died without them, and it was fine.

Re: The Last 1%

#36

Post by doctor_eval »

I honestly thought this was going to say “marketing, sales, support”! The things I hate to do… but have to do.

But actually this blog is apparently talking about a single feature of a larger product. In which case the larger product should already have the necessary infrastructure (metric collection and dashboards), and so perhaps it is just 1% of the time.

For the kind of indie style product I’ve worked/am working on, I think these are more like 20% issues, but I don’t think that you need all - or even most - of the items listed until after your product gets a bit of traction. Better to launch an 80% product now than a 100% product in 6 months.

Until you’ve got many customers, you can get most of the usage, performance and error instrumentation from watching the appropriate logs, perhaps adding a bit of dedicated perf logging in performance critical areas. Building all this other infra too early is just a waste of time.

In fact I’d say that, in the early days, continuous deployment and a bit of testing is more important than instrumentation. It’s way more difficult to retrofit CD, and it saves so much time, especially when you’re pushing lots of updates, i.e. at the start of a project.

But like I say, my comments apply to a new product. Not a new feature of an existing product. In which case I’d expect engineering standards and infrastructure to be well defined.

Re: The Last 1%

#37

Post by pc86 »

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-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.

Yes you'll be in a much better place if you have it, but if your competitors and building features and iterating the product while you're building out instrumentation and dashboards, you're likely going to lose over time.

Re: The Last 1%

#38

Post by xtagon »

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…

I think where the semantics become relevant is that people say "project" to mean "product". When it's a product, it might never be 100% done, and it might be a poor idea to try to frame it as if it could be. But some projects aren't products, and don't have perpetual stakeholders, and for some of those it can be possible to set realistic 100% done targets and reach them.

Re: The Last 1%

#39

Post by t-writescode »

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…

Or win, while the other company has had

  * churn
  * turnover and nothing of theirs is documented, everything is tribal knowledge
  * their former "star performers" are now trapped working exactly on this single project because they're the only one that knows how it works.
  * customer loss because fixes take weeks since you don't even get the metrics to know that their systems are down and their customers have come to believe them to be unreliable.

Re: The Last 1%

#40

Post by xmprt »

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…

While that's true, there are also projects that can live and die with very few code changes for years. And as long as those projects are continuing to provide value for their lifetime, I'd call that a successful project.

On the other hand, I've seen projects get to 99% and they provide value for a few months and then because they never get to 100%, every time there's an issue no matter how small, it's very difficult to debug and the original owner has moved on to a new project or left the company so users are left holding the bag or they just end up deciding to stop using the product or build a new one.

Post reply on HN