15 ms·

The Last 1%

213 points by jram930 3y ago

t-writescode 3y ago
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'.
- baal80spam 3y ago
  Not to mention a good AT coverage - it can easily take 20% of project time, and often much more.
  - huganabaga 3y ago
    But it saves heaps of work after. Far beyond 20%. (The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)
- lumost 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
      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.
    - huganabaga 3y ago
      > 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. And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time. Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
      - t-writescode 3y ago
- _a_a_a_ 3y ago
  Documentation is a deliverable as much as software. Just as important too.
- hackernewds 3y ago
  > 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 This is why having a solid BI and Data science org is underrated. To assign these to eng teams is disparaging for every org.
_xivi 3y ago
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 https://news.ycombinator.com/item?id=36967594]
- tikkun 3y ago
  Yes, I initially thought that the OP was someone resubmitting that post, in fact
  - jram930 3y ago
    Interesting, I didn't even see this the other day. Guess it's a common sentiment :)
    - azhenley 3y ago
      Really? The structure is almost an exact replica of my post. The wording of the first paragraph and the text before the list is also very, very similar. I thought this was a direct response to my post.
- azhenley 3y ago
  I can't tell if the author is agreeing with my blog post or mocking it :D https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html
  - _xivi 3y ago
    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.
bluefishinit 3y ago
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.
- zwieback 3y ago
  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.
  - bluefishinit 3y ago
    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.
  - freetanga 3y ago
    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.
nine_zeros 3y ago
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 3y ago
  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.
  - huganabaga 3y ago
    My personal conclusion is to never work under management who are not software engineers themselves. All my bosses understand what building great software entails since they could do it themselves. So what I do to improve qualiry has always their backing. And nobody can BS them into some nonsense.
xyzzy4747 3y ago
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 3y ago
  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 3y ago
    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.
wcerfgba 3y ago
Not on the list: reflection, in the vein of action research.
coldtea 3y ago
>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.
- hackernewds 3y ago
  > 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
  - coldtea 3y ago
    >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".
deleted 3y ago
[deleted]
ChrisMarshallNY 3y ago
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/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
quickthrower2 3y ago
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.
angarg12 3y ago
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.
- xtagon 3y ago
  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.
- xmprt 3y ago
  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.
- jrochkind1 3y ago
  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.
doctor_eval 3y ago
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.
pc86 3y ago
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.
- t-writescode 3y ago
  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.
- User23 3y ago
  > 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?
  - lazyasciiart 3y ago
    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)
Pxtl 3y ago
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?
- huganabaga 3y ago
  Everybody has time to write an automated test. If you don't, then you don't have time to write code in the first place. That's the difference between professional software engineering and just hacking something quick in your free time. You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software any different.
  - Pxtl 3y ago
    Fair, automated tests are important, but it's still ludicrous to call automated testing "1%". It's a lot. And let's be real - there isn't always the time, requirements being what they are, especially for properly isolated unit tests. But I'm always an advocate for a "worse-is-better" integration-test-script that requires a full test environment rather than having to build a full mock architecture. Unit tests are the gold standard, but a few integration tests per-feature are a good bare minimum.
deleted 3y ago
[deleted]
huganabaga 3y ago
Putting "automated testing" into the last 1% is the issue right there. It needs to be part of what you are doing from the start. You are done when your automated tests are complete and reliably green, not when some underpaid tester in Bangladesh gives their thumbs up. Ideally your documentation is tightly integrated with your tests too, then it will be done as well and won't go stale.
gorenb 3y ago
I don’t think it’s very likely that a developer will ever implement automated testing.
- sethammons 3y ago
  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.
  - john-tells-all 3y ago
    Seconded. Recently while refactoring I realized I was breaking nearly everything. Most code didn't have tests -- I'm working on an experiment. So, I coded 3-4 tests of the "run the main program and if it doesn't crash then it passes" style. These tests are silly, but they catch lots of refactoring bugs! And it only took 30 seconds to write the test. If later I decide the actual _values_ matter, I can add another test, but this "break glass" test is already giving me benefits. I can refactor bravely and see how much stuff goes up in flames. Very useful!
ergocoder 3y ago
If you've finished 99%, and your product isn't successful, the last 1% wouldn't matter. Actually, I would even go with the 20-30% threshold. Many great products got traction from the start. Think Twitter, Stripe, Facebook, Craiglist, and etc. Even the first version of iPhone was far from done.
bradley13 3y ago
Huge emphasis on metrics: 6 of his 10 points. However, those only apply to a rather small subset of projects, mostly big web apps or SaaS projects. In my recent experience, the biggest point that applies to the vast majority of software projects is his second point: user documentation. As often as not, you get pointed to a website, on which it is impossible to find anything useful. Maybe there's an FAQ, but the questions were never asked by actual users. If there's a problem, or something isn't properly documented? Maybe there's a support email, or an online ticketing system. Whether you'll get an answer is a lottery. For one piece of software, I submitted a ticket in February asking for clarification of their poorly documented API. No answer, so in March I submitted another ticket requesting an answer to the first ticket. Promptly answered: I just need to be patient. To date (August), nothing. Development schedules for anything "online" are always crazy: You've got to get something out there, fast. Decent documentation never happens, because the company is already off on the next project.
thyrsus 3y ago
Doing devops/sysadmin, I frequently find myself spending 90% of my time on the last 1% of systems that I can't declare out of scope but that are broken/nonconforming for "business reasons". I'd be 10x more productive if I could just turn those off. Every time, I try to make the fixes/write the code that will smooth the next time, but the next thing always arrives before I finish. I've written enough code to recognize the same pattern in any large codebase.
Nevermark 3y ago
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.
patrulek 3y ago
Am i the only one who hates these minimalistic/retro-looking blogs with a few posts that sells you truisms or already known facts?
happytiger 3y ago
The author is confusing the journey for the destination. There is no finished. Only more done. Or less done.
rustybolt 3y ago
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.
- HPsquared 3y ago
  I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.
  - anonymous_sorry 3y ago
    If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?
    - HPsquared 3y ago
      Communication between the builders and maintainers, including "costly signals" (commercial consequences for poor work, poor reputation, losing contracts etc). There are a lot of builders out there.
yakkomajuri 3y ago
Awfully similar to a post we just had on here: https://news.ycombinator.com/item?id=36967594 https://news.ycombinator.com/item?id=36967594. Including the fact that both are short and finish with a list of items. Interestingly neither post seems to be at 100% (not a criticism!), which kinda relates to what I said in the other discussion: https://news.ycombinator.com/item?id=36971378 https://news.ycombinator.com/item?id=36971378
lacoolj 3y ago
screw all that stuff for now and ship it :) seriously tho, that stuff is very important and should get some priority but only after you have customers. if you are not in a position to worry about revenue (maybe you won the lottery or this is a project backed by Google), then do as many of those things beforehand as you can. but your hardest sale is the first one, which will be even harder the longer you wait to put it on the market.

213 points by jram930 3y ago

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

baal80spam 3y ago
Not to mention a good AT coverage - it can easily take 20% of project time, and often much more.
- huganabaga 3y ago
  But it saves heaps of work after. Far beyond 20%. (The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)
lumost 3y ago
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 3y ago
  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 3y ago
    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 3y ago
    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.
  - huganabaga 3y ago
    > 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. And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time. Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
    - t-writescode 3y ago
_a_a_a_ 3y ago
Documentation is a deliverable as much as software. Just as important too.
hackernewds 3y ago
> 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 This is why having a solid BI and Data science org is underrated. To assign these to eng teams is disparaging for every org.

_xivi 3y ago

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 https://news.ycombinator.com/item?id=36967594]

tikkun 3y ago
Yes, I initially thought that the OP was someone resubmitting that post, in fact
- jram930 3y ago
  Interesting, I didn't even see this the other day. Guess it's a common sentiment :)
  - azhenley 3y ago
    Really? The structure is almost an exact replica of my post. The wording of the first paragraph and the text before the list is also very, very similar. I thought this was a direct response to my post.
azhenley 3y ago
I can't tell if the author is agreeing with my blog post or mocking it :D https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html
- _xivi 3y ago
  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.

bluefishinit 3y ago

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.

zwieback 3y ago
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.
- bluefishinit 3y ago
  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.
- freetanga 3y ago
  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.

nine_zeros 3y ago

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 3y ago
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.
- huganabaga 3y ago
  My personal conclusion is to never work under management who are not software engineers themselves. All my bosses understand what building great software entails since they could do it themselves. So what I do to improve qualiry has always their backing. And nobody can BS them into some nonsense.

xyzzy4747 3y ago

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 3y ago
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 3y ago
  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.

wcerfgba 3y ago

Not on the list: reflection, in the vein of action research.

coldtea 3y ago

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

hackernewds 3y ago
> 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
- coldtea 3y ago
  >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".

deleted 3y ago

[deleted]

ChrisMarshallNY 3y ago

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/ https://littlegreenviper.com/miscellany/leaving-a-legacy/

quickthrower2 3y ago

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.

angarg12 3y ago

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.

xtagon 3y ago
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.
xmprt 3y ago
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.
jrochkind1 3y ago
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.

doctor_eval 3y ago

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.

pc86 3y ago

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.

t-writescode 3y ago
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.
User23 3y ago
> 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?
- lazyasciiart 3y ago
  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)

Pxtl 3y ago

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?

huganabaga 3y ago
Everybody has time to write an automated test. If you don't, then you don't have time to write code in the first place. That's the difference between professional software engineering and just hacking something quick in your free time. You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software any different.
- Pxtl 3y ago
  Fair, automated tests are important, but it's still ludicrous to call automated testing "1%". It's a lot. And let's be real - there isn't always the time, requirements being what they are, especially for properly isolated unit tests. But I'm always an advocate for a "worse-is-better" integration-test-script that requires a full test environment rather than having to build a full mock architecture. Unit tests are the gold standard, but a few integration tests per-feature are a good bare minimum.

deleted 3y ago

[deleted]

huganabaga 3y ago

Putting "automated testing" into the last 1% is the issue right there. It needs to be part of what you are doing from the start. You are done when your automated tests are complete and reliably green, not when some underpaid tester in Bangladesh gives their thumbs up. Ideally your documentation is tightly integrated with your tests too, then it will be done as well and won't go stale.

gorenb 3y ago

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

sethammons 3y ago
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.
- john-tells-all 3y ago
  Seconded. Recently while refactoring I realized I was breaking nearly everything. Most code didn't have tests -- I'm working on an experiment. So, I coded 3-4 tests of the "run the main program and if it doesn't crash then it passes" style. These tests are silly, but they catch lots of refactoring bugs! And it only took 30 seconds to write the test. If later I decide the actual _values_ matter, I can add another test, but this "break glass" test is already giving me benefits. I can refactor bravely and see how much stuff goes up in flames. Very useful!

ergocoder 3y ago

If you've finished 99%, and your product isn't successful, the last 1% wouldn't matter. Actually, I would even go with the 20-30% threshold. Many great products got traction from the start. Think Twitter, Stripe, Facebook, Craiglist, and etc. Even the first version of iPhone was far from done.

bradley13 3y ago

Huge emphasis on metrics: 6 of his 10 points. However, those only apply to a rather small subset of projects, mostly big web apps or SaaS projects. In my recent experience, the biggest point that applies to the vast majority of software projects is his second point: user documentation. As often as not, you get pointed to a website, on which it is impossible to find anything useful. Maybe there's an FAQ, but the questions were never asked by actual users. If there's a problem, or something isn't properly documented? Maybe there's a support email, or an online ticketing system. Whether you'll get an answer is a lottery. For one piece of software, I submitted a ticket in February asking for clarification of their poorly documented API. No answer, so in March I submitted another ticket requesting an answer to the first ticket. Promptly answered: I just need to be patient. To date (August), nothing. Development schedules for anything "online" are always crazy: You've got to get something out there, fast. Decent documentation never happens, because the company is already off on the next project.

thyrsus 3y ago

Doing devops/sysadmin, I frequently find myself spending 90% of my time on the last 1% of systems that I can't declare out of scope but that are broken/nonconforming for "business reasons". I'd be 10x more productive if I could just turn those off. Every time, I try to make the fixes/write the code that will smooth the next time, but the next thing always arrives before I finish. I've written enough code to recognize the same pattern in any large codebase.

Nevermark 3y ago

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.

patrulek 3y ago

Am i the only one who hates these minimalistic/retro-looking blogs with a few posts that sells you truisms or already known facts?

happytiger 3y ago

The author is confusing the journey for the destination. There is no finished. Only more done. Or less done.

rustybolt 3y ago

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.

HPsquared 3y ago
I fond it works to have a division of labour between builders and maintainers. Just like in property management, the different phases need a different approach.
- anonymous_sorry 3y ago
  If builders don't experience the maintenance costs of their decisions, how will they ever learn? And even if they do learn, where's their incentive to do it better next time?
  - HPsquared 3y ago
    Communication between the builders and maintainers, including "costly signals" (commercial consequences for poor work, poor reputation, losing contracts etc). There are a lot of builders out there.

yakkomajuri 3y ago

Awfully similar to a post we just had on here: https://news.ycombinator.com/item?id=36967594 https://news.ycombinator.com/item?id=36967594. Including the fact that both are short and finish with a list of items. Interestingly neither post seems to be at 100% (not a criticism!), which kinda relates to what I said in the other discussion: https://news.ycombinator.com/item?id=36971378 https://news.ycombinator.com/item?id=36971378

lacoolj 3y ago

screw all that stuff for now and ship it :) seriously tho, that stuff is very important and should get some priority but only after you have customers. if you are not in a position to worry about revenue (maybe you won the lottery or this is a project backed by Google), then do as many of those things beforehand as you can. but your hardest sale is the first one, which will be even harder the longer you wait to put it on the market.