[HN Gopher] The Last 1%
___________________________________________________________________
The Last 1%
Author : jram930
Score : 61 points
Date : 2023-08-08 20:51 UTC (2 hours ago)
(HTM) web link (jaredramsey.com)
(TXT) w3m dump (jaredramsey.com)
| bluefishinit wrote:
| 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 be boiled to avoid the
| uncomfortable fact that good product is developed intuitively by
| good product people. This "last 1%" is somewhat akin to waterfall
| development.
|
| Stay lightweight, hire people proven to design and ship awesome
| product and iterate as fast as possible. Use your own product.
| Talk to people who use your product. Take chances with your
| product design. Don't let organizational turf wars shape the
| product (something telemetry driven development is notorious
| for). Good old fashioned craftsmanship and creativity can go a
| long way. It's how new industries are born.
| dalyons wrote:
| intuitively i agree with you, i've seen a lot of the pseudo-
| science.
|
| But curious, can you elaborate on how telemetry driven
| development leads to organizational turf wars? I think i've
| seen that too but interested to hear your thoughts.
| bluefishinit wrote:
| Everything from what gets tracked to how the data gets
| interpreted. It also can put a target on certain growth areas
| that will attract the more "ambitious" people from the
| company. All will try to make the case with the telemetry
| data.
|
| Does more time on a page mean users are more engaged or are
| they struggling to find out what's going on? Depends on which
| product manager can make a better case, probably involving
| even more telemetry which has to get prioritized.
|
| In the creative IC model, the designer and developer work to
| solve a problem based on their experience building product.
| Or someone has a kick ass idea one day and just implements it
| creating a step change in usage. That type of environment
| requires freedom and trust, it also puts a lot of control in
| the hands of the ICs which is why it's not popular with
| product managers, directors, vps...
| vasco wrote:
| I agree with you in spirit but you have to realize that
| every developer and designer pairs will think they are the
| ones that know what they are doing and should have the
| trust. I've seen trust be given for periods of years and
| teams simply wasting time and not meaningfully improving
| anything. This only works with good product people on board
| and most product people aren't any good at product.
| mastazi wrote:
| I only partially agree with you because that list also includes
| things like documentation, error metrics and alerting... those
| have nothing to do with marketing folks pushing for more
| telemetry. Things like documentation and alerting are something
| a good engineer should worry about IMHO
| preommr wrote:
| > None of those things are going to make a bad feature
| successful and not doing these will not make a good feature
| unsuccessful.
|
| Which is why the article says: "This last 1% isn't just what
| separates a great product from a good product, it's what
| separates a product that might not eventually fail from one
| that will eventually fail."
|
| A feature can easily be successful while being impossible to
| maintain because when it comes time to pay the cost, all the
| main people involved have already claimed the required benefits
| and jumped ship.
| zwieback wrote:
| 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.
| freetanga wrote:
| Agree. Tech is a very broad universe. Is not the same to
| create a consumer facing platform for a new business than
| creating a Core System for a Telco, Utility or Bank. In those
| cases, the 1% (minus documentation) is crucial, as core
| features are not removed nearly ever.
|
| When you are experimenting with consumers and a feature might
| end up being a failure, then yes some of those items could be
| cataloged as tech debt of sorts.
| bluefishinit wrote:
| Yep, I've worked on consumer products with decade plus
| lifespans. I was lucky enough to have worked in places that
| valued creativity, so shipping interesting features was
| always prioritized over direction by committee with data
| augmentation. I'll say that the end-users really loved that.
| They for the most part don't want you rearranging their
| living room (so to speak) they want new home additions.
| quickthrower2 wrote:
| 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.
| forrestthewoods wrote:
| > 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
|
| You said what I was thinking but couldn't come up with the
| words. These aren't the difference makers.
|
| Every "successful product" is held together with spit, glue,
| and an ocean of tech debt. There is no utopia.
| angarg12 wrote:
| 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.
| nine_zeros wrote:
| I will do these for myself and my team but only if management
| recognizes this as work. If my performance review comes back with
| a low rating despite me having done this work, I am not going to
| do this any longer. Management can feel free to deal with
| consequences.
| justin_oaks wrote:
| And this is the crux of a lot of software developer angst. Most
| management doesn't know the benefit of code quality
| (refactoring), unit tests, metrics/monitoring, security, etc.
| and will push back against the extra work they take.
|
| Good software developers do know the benefit of those things.
| They resist the management's efforts to ignore those things. In
| the end, the software developer often give in because they know
| who has the power.
|
| There's balance to be had, and cases where's it's not worth it
| to put in more effort on certain things... but the boss rarely
| has any visibility into the tech side of things.
| [deleted]
| t-writescode wrote:
| 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 defined as 'minimum to click
| button', not 'minimum to support button'.
| lumost wrote:
| 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 away with incompetent engineers. However if
| you repeat this cycle on the same code base 100x over, every
| feature gets harder. Eventually you hit a point where no one
| really knows how to do anything anymore as a feature that used
| to take 2 weeks now takes 8 months.
|
| "Completion or bust" works really well when you can't take a
| feature back... ever. However the definition of completion
| tends to grow over time. I've seen launch checklists which
| amounted to 6 month projects on their own (for both good and
| bad reasons). Sometimes completion becomes an excuse for
| architectural astronauts to enforce a change resistant paradigm
| on the code, eliminating any gains from completionism. Other
| times, the engineers and managers become convinced that any
| change will take N months and start ignoring everything that
| doesn't look like it will provide N months of value.
|
| 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.
| t-writescode wrote:
| I love this whole post!
|
| Small add: "generally competent engineers" can sometimes
| (almost) inline most of the code completeness details for
| cheap, reducing their cost greatly.
|
| Writing documentation is always a time sink, though, in my
| experience. Or maybe I'm just not good at it :P It's usually
| an additional day of work overall, though.
| tracker1 wrote:
| Depends on what you're doing... For a developer focused
| documentation, I often will write a bit of the
| documentation up front as a project is getting setup with
| the intent on how it should work locally (or per
| developer). Then fill in details as each part gets more
| flushed out. Same for library APIs, command-line
| scripts/tools etc.
|
| For end-user products with a user interface, less so as it
| comes down to being flexible... similar with dashboards, as
| a developer I often don't know what is wanted up front...
| when something is asked for and you learn the domain more,
| it can come together easier. Larger projects with a front
| end component and many developers, nearly have to forget it
| at the dev level.
| Spellinator wrote:
| Writing docs, especially detailed and complete, can really
| save you in the long run. Plus the people that come after
| you will greatly appreciate your efforts.
| _a_a_a_ wrote:
| Documentation is a deliverable as much as software. Just as
| important too.
| baal80spam wrote:
| Not to mention a good AT coverage - it can easily take 20% of
| project time, and often much more.
| coldtea wrote:
| > _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 the above are even important in launching a product, much
| less an MVP.
|
| Startups have raised hundreds of millions and get millions of
| users without any of those. In fact they'd probably just slowed
| them down.
| ChrisMarshallNY wrote:
| 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/
| quickthrower2 wrote:
| 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.
| xyzzy4747 wrote:
| If something isn't making for example the cost of a fulltime
| salary in revenue then the last 1% is a waste of time.
| freetanga wrote:
| 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.
| cableshaft wrote:
| 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.
| imadj wrote:
| Similar take was shared recently, except it put more emphasis on
| marketing in the last 10%:
|
| Stopping at 90% [https://news.ycombinator.com/item?id=36967594]
| azhenley wrote:
| I can't tell if the author is agreeing with my blog post or
| mocking it :D
|
| https://austinhenley.com/blog/90percent.html
| imadj wrote:
| It seems like a different take with similar sentiment: The
| project isn't over once it's functional.
|
| It's a nice coincidence tho, you and OP should collaborate on
| a joint research to get the bottom of it.
| tikkun wrote:
| Yes, I initially thought that the OP was someone resubmitting
| that post, in fact
| jram930 wrote:
| Interesting, I didn't even see this the other day. Guess it's
| a common sentiment :)
| wcerfgba wrote:
| Not on the list: reflection, in the vein of action research.
___________________________________________________________________
(page generated 2023-08-08 23:00 UTC)