15 ms·

Stopping at 90%

349 points by alexmolas 3y ago

daemon_9009 3y ago
if you create a project, create it as if people would use it, not to keep it in github repo, if you keep your project to yourself the entire effort you had put in the project is completely uselesss.
MattHeard 3y ago
I prefer to stop at 80%.
nsmog767 3y ago
I'm a nontechnical marketer with a senior person who builds internal tools. We very much have this problem. We get it...most of the way there. But without a strong system to distribute it, get feedback, get buy-in, a lot of the work is underutilized.
- grumpy_coder 3y ago
  I do feel the article isn't clear on what the context is, but it sounds like it is really this sort of corporate 'project' like internal research or tools. And from years of doing these things I think they massively underestimate the 'system' as you put it. This system involves process, culture, rewards and a ton of politics. It has some very unique challenges different from shipping products. Often your total addressable market is one team in the company, so product analogies aren't much help. You really need to gain political power to get buy-in. Or in today's corporate environment just be okay with finishing the task to 90% This system needs to be in place prior, building it isn't 10% tacked on the end of a small project.
huijzer 3y ago
Yes but the problem is that engineering projects tend to consist of two halves. There is the first 90% of the work and there is the second 90% of the work.
- huijzer 3y ago
  Can we start calling "evangelism" "sales" again, by the way? Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology.
  - dragonwriter 3y ago
    > Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology. While both come from religion, an evangelist is not the same thing as a theologian.
    - deleted 3y ago
      [deleted]
  - wumms 3y ago
    > evangelist - religion: a person who tries to persuade people to become Christians, often by travelling around and organizing religious meetings - opinions: someone who often talks about how good they think something is, and tries to persuade you to have the same opinion - religion: one of the writers of the four books in the Bible about Jesus Christ https://dictionary.cambridge.org/de/worterbuch/englisch/evangelist https://dictionary.cambridge.org/de/worterbuch/englisch/evan...
    - darkclouds 3y ago
      And yet they omit Lawyers in front of juries and Lexicographers writing the next edition of a dictionary. Is there any logic to this exceptional world?
      - hgsgm 3y ago
        Yes, but it's fuzzy.
        darkclouds 3y ago
secretcombos 3y ago
Promote as you build is the way to go (if you can). I'm posting my book online, article by article. That way you get real-time feedback as to what works at what doesn't.
- marginalia_nu 3y ago
  Yeah. I do think there are pitfalls to this though. There's a tendency to want to smooth over problems and mistakes and amplify successes, which also makes the story you are telling pretty boring and artificial. Basically: Let me tell you a story of the time we tried to play golf. We went to the US Open and signed up with our fantastic team of engineers, it wasn't easy and our team had to work long hours to figure it out as we went but thanks to teamwork we struck hole in one every time. We're fantastic at golf, and the audience cheered for our amazing teamwork and leadership success, and Tiger Woods came forward from the crowd to shake our hands and was was very impressed with what we were doing in such short time. Like this story had no downs, it's completely flat and omits any problems and greatly exaggerates the successes. It's also like not far off the median linkedin post about a project in progress. It removes all the things that makes a story compelling. What were the problems? How were they overcome? What were the lessons learned?
  - seabass-labrax 3y ago
    The risk to this is that your competitors seize the opportunity to criticise your mistakes as if you're hiding them, even if you wrote about them yourself! As such, one justification for keeping problems secret is that your competitors don't know about them. It's unfortunate, as it stops a lot of good-faith collaboration, where strangers will come and offer support.
nlpalks 3y ago
I was delighted to see this headline and post. The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others: "Find someone that can poke holes in your work, then go address them." The underlying issue is widespread in OSS projects. Increasingly it is all about features (for which those who are paid to "work" on projects are rewarded). Others spend 10x the amount to fix the features or leave the projects or are driven out by the corporate developers.
- maccard 3y ago
  > The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others: Marketing _is_ real work. Software is only useful if it's being used. Now, it's up to the author (or PO/PM) to define _who_ the users are. If it's an internal team, a slack message to that team's channel saying "hey I made X do y" is marketing, but necessary. Sending a PR to an OSS project is marketing. Updating the docs to show how to use your new thing is marketing.
- smitty1e 3y ago
  > "Find someone that can poke holes in your work, then go address them." What does "address" them mean? If starting from scratch on a fresh project is the easiest way to factor out the design flaw at the heart of my whoopsie, does that count as addressing the problem at a higher level, or blowing off my current whoopsie at 90%?
- marginalia_nu 3y ago
  > real work This is a a very "programmer" view of the world that the work is when code is being produced, and everything else (especially anything involving people) is not actually productive. You can have enormous impact with that other form of work. Marketing is huge, even for open source projects, even hobby projects. It very directly affects your ability to have an impact on the world. If you do zero marketing, the only impact you have is what you do with your hands, which is not a lot in most cases. Blogging and talking about what I do (=marketing) has opened doors to the extent that I've been able to quit my job and do full time work on what was once a zany hobby project to pass the time during covid isolation. That is, investing some time in marketing in the past let me spend more time "working" on code in the present. The impact has been kind of insane. I've been in The New Yorker because of this. I've done radio interviews. Nothing of this would have happened if I wasn't constantly writing about my projects, constantly making rings on the water stretching farther and farther out. It takes a while to get going and pick up momentum, but the accumulated effect can get very strong. This is marketing. It doesn't have to be shallow and corporate and SEO optimized and pestering users for newsletter subscriptions. It can be authentic and personal... but it's still marketing. If anything, that's the best sort of marketing. I believe what I write, I stick to my principles and I'm not trying to bullshit anyone. That stuff shines through.
ansc 3y ago
You could as easily write: We spent 4 months building a software system, running experiments, writing an academic paper, and submitting it to a journal for publication. So now we are done. The end. Right? Yes! This is what I call stopping at 90%! The remaining 10% is far more difficult to track and often has no clear stopping point. It's often better to skip the last 10% and move on.
- alexmolas 3y ago
  In my experience this last 10% is the one that differentiates great work from good work. In my team we use to call it "put the bow on the gift". Receiving a well packaged gift makes the difference.
- deleted 3y ago
  [deleted]
Kiro 3y ago
This seems like a non-existent problem in software development. Who has ever felt being done and satisfied with anything? It's always the opposite with an endless backlog of improvements.
- poisonborz 3y ago
  You are talking about core work. The article is about tangential work, which is just as, if not even more neglected in sw dev. In academia there is at least a tradition of publishing, lecturing and review.
  - zelphirkalt 3y ago
    What is core work and what is tangential work?
    - poisonborz 3y ago
      Writing code vs documentation, support, marketing etc.
      - graphviz 3y ago
        This may be a fallacy. It is all connected. Some of the connections are not obvious at first. It's very tempting to create interesting features for your own edification or satisfaction, and leave them nearly undocumented. Years later, kind-hearted strangers discover these in the code and wonder why no one knows about them. Sometimes, it's like code that you just wrote for yourself might as well not even exist for the rest of the world. That's just one facet of this situation.
- lvturner 3y ago
  Yeah, I see this all the time in my team and this article really succinctly sums it up. It doesn't negate the backlog and the never-ending work - the takeaway here for me is that sometimes you do indeed need to step back and say "Hey me and the team worked really hard on this, come look"
sixthDot 3y ago
Very well known https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule. > What are some common activities to go from 90% to 100%? To the list I'll add - 100% coverage - rewrite it in Rust (ha ha)
- winwang 3y ago
  - Add dependent types
- Karellen 3y ago
  I'll admit, to me the point that the author considers 90% is where I consider 99%. IMO, getting from 90% (it works and does the right thing with any valid input) to 99% involves things like - paying down all technical debt - handling malformed or adversarial inputs, including all edge-cases, "reasonably" - better documentation; tutorials, how-tos, explainers, and references. In multiple formats (don't forget your `man` page). - checking for low-hanging perf/memory wins. - interface polish. Is there a long-running operation that might benefit from a progress bar? Or some other indicators which aren't strictly necessary, but would help users model of the state of the program?
amelius 3y ago
I see this a lot with hardware drivers. They tested it once on one system and it worked, then called it a day.
- davidgerard 3y ago
  MVP, which I keep seeing in practice as stopping as far before 90% as you can.
ChrisMarshallNY 3y ago
90%? More like 50%. Shipping software has a lot of non-coding stuff. We are in the last [coding] lap of a project that has been ongoing for two years. I think we probably still have at least another eight to ten months of stuff ahead of us before we ship.
RyanHamilton 3y ago
If the author has interested you in the possibility of doing the other 10% of work, I would recommend the book "Traction - How any startup can achieve explosive customer growth" by Weinberg and Mares. It actually suggests gaining traction at the same time as developing to ensure a constantfeedback loop. In some cases you will even want to build parts of your product to help you gain traction.I think they even mentioned alternating each week, one week dev, one week marketing, i.e. 50%.
- wouldbecouldbe 3y ago
  It’s can work but they never talk about the operational & support costs such an approach has, let alone the emotional price
muzani 3y ago
More than 80% of the work is doing the work, the remaining 20% is selling that you did it. More than 80% of the results come from selling it, 20% comes from doing it. It's the case with research, building startups, homework, whatever. If it's not pushed into production and marketed, the value is there, but very tiny. Some people see the results and make the mistake of spending more than 20% of their focus selling it, but nobody respects people who talk a lot but do little.
- _xivi 3y ago
  What if you don't want to sell it? Does that mean you did 100% or the remaining 10% shift to sth else
- taneq 3y ago
  About 80% of the doing-the-work bit is figuring out what you're doing and how. There's a lot more work to work than just the bit that we think of as the work.
Tade0 3y ago
Related to this I have a measure that I call "general effectiveness" - mine is 83-86% meaning, when I'm, in my view, perfectly prepared, the outcome is actually closer to that. Every exam I took eventually hovered around that number - assuming I studied. This was particularly visible in math class in high school, where our teacher put emphasis on consistent work. It's a useful model because on one hand if I have a score, I can tell if I did my best and how much of my success can be attributed to individual effort. On the other, when I don't have a score, I at least have a reasonable upper bound on how much was done and how well.
yobbo 3y ago
> ... If no one knows about it or won't give it a chance, then it's as if it never happened. It is rational to stop somewhere between 0% and 100%. There is no guarantee you will find traction in the last 10% or the last 1%, if you get that far. It might have been rational to stop at 17% and instead spent the time and resources on something else. To make an honest and rational decision, there should be go-conditions at several points along the project. Work stops when conditions aren't met.
- KnobbleMcKnees 3y ago
  A version of what you're describing is the sunk cost fallacy
  - dizhn 3y ago
    My familiarity with the fallacy enabled me to quit watching John Wick in the last 10 minutes. 10 minutes saved is not nothing.
    - selimthegrim 3y ago
      You didn’t quit when the dog got killed?
      - dizhn 3y ago
        Come to think of it, I think it was John Wick 2. Bonus site: https://www.doesthedogdie.com/ https://www.doesthedogdie.com/
    - sfink 3y ago
      I wish I had been able to do that. But at least I get to see announcements for John Wick 4 and get a warm fuzzy feeling that I have escaped watching 3 whole movies, and thus have an extra 6 hours in which to do something better in my life with an exceptionally low bar for "better".
_xivi 3y ago
> where as the remaining 10% is far more difficult to track and often has no clear stopping point. The problem isn't that it's difficult to track. It's not even clear what the remaining 10% is, or if it's 10% to begin with. If you asked 10 people what the rest 10% is about, you'll get 10 different answers.
twodave 3y ago
From an academic perspective, sure? I guess? But most things done in the name of academia are for the purpose of learning, so the goals are different. If your goal is to build a PRODUCT this is stupid advice. You really want to stop once your primary use cases go end to end. It doesn't even need to scale. Go make a sale or whatever flavor of "get users" your product needs to be validated. Most products don't get the benefit of being able to stand on their own. Every customer you add comes with their own unique last 10% that you'll need to work on to get them to sign up. So go find out what THOSE requirements are, or you'll end up doing the wrong "last 10%". Oh, and make sure you understand what the client is actually asking for, or you'll end up doing the wrong 10% and losing your next big customer, which can be a super demoralizing experience.
deleted 3y ago
[deleted]
JacobSeated 3y ago
Things rarely reach a 100% and that's okay imo – as long as I am still making progress. It's hard to find time and energy for dedicated work sessions on personal projects with a full time job. Small incremental improvements ftw!
w-m 3y ago
I put a lot of work into doing the last 10% for a project recently, and I'm not convinced yet that I'll be getting anything out of it, other than my own satisfaction. After my colleagues and I got our paper (on real-time depth estimation with an event camera and a laser projector [0]) accepted at a workshop, we could have just dumped the convoluted, messy research code on GitHub and be done with it. For other people to figure it out, if they really cared. But I sat down and completely rewrote all the scaffolding around the presented algorithm, to make for a smooth and fast demo. Wrote up documentation for the implementation, gave it a command line interface, set up a script to reproduce the measurements in the paper with a single execution (downloading the required data and comparing several methods). Broadcast in all channels available to me (institution press release, LinkedIn posts, GitHub awesome list linkings). And I actually brought the demo to the workshop, which wasn't required at all, I could have just presented it as a poster. The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not. Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success. [0]: https://fraunhoferhhi.github.io/X-maps/ https://fraunhoferhhi.github.io/X-maps/
- sidmitra 3y ago
  There might be people years from now that could benefit from your work. Caring about something and putting it out there is never in vain.
  - DoughnutHole 3y ago
    It might not be in vain, but it can often be a poor balancing of priorities. The last 10% can easily require as much work as the first 90% - perfection is expensive. If your reason to perfect something is internal (high personal standards and taking pride in your work) then great - take the opportunity cost in stride and finish something you'll be satisfied with. But if it's external (eg. making it just that bit more impressive to others) I'd say usually your time would be better spent moving on to the next thing.
jongjong 3y ago
It's hard to know why projects didn't get traction. Is it because the documentation is not as good as it could have been? Is it because the marketing was insufficient? There are some projects out there which are similar to some of my projects and which did get traction and they have basically the same level of polish and documentation. I feel like it just comes down to marketing which itself just comes down to social connections. I'm quite certain now that if someone like Elon Musk looked at some of my projects and promoted them, they'd get tons of traction. The user feedback on some of my projects has been very good but it appears that none of my users has been a high-exposure individual. On one of my open source projects which did get a little bit of initial traction, at one point traction slowed down and I was paranoid and thought that the code could be improved more and I reworked a lot of stuff to make it work optimally with Kubernetes. But some years down the line I found out that a significant subset of my users actually preferred how it worked before and were still using the old version. I still think it was a good move because the new architecture is much simpler and more elegant but probably not necessary as it didn't help my project get more traction. Sometimes the only problem is just marketing and social networking and if you're not born at the right place and right time, there's nothing you can do about it.
server_man3000 3y ago
This article just breeds classic toxic work mentality. There is nothing wrong doing 90% of a project. Hell, I’ve learned the most doing just 50-70% of side projects and moving to other ideas faster.
blitz_skull 3y ago
The Pareto Principle would beg to differ. I highly doubt you’re getting the same value out of the remaining 10% that you got out of the first 90%. Or maybe I have it backwards and the 10% is 80% of the value? But no, that makes me uncomfortable considering my pattern of unfinished projects so I’m going to go with my first theory.
drsim 3y ago
I call this the definition of done. It’s when my kids think they’re done with breakfast but haven’t washed their hands. It’s when a PM is done with a feature when it’s deployed to production but its success hasn’t been measured. It’s when I’m done with writing a blog post but haven’t proofread it. Defining done and having stakeholders agree on the definition is how we move forward. Without that, the entropy of work trends to empty busyness.
pachico 3y ago
This is why, at least at work,you need a strict definition of done. A DoD isn't only useful to you and your team but also to the rest of your organisation so that everyone knows that you might still be working on a task/project although you have already finished the most visible part of it. It helps, in general, to manage expectations.
deleted 3y ago
[deleted]
albert_e 3y ago
I have the opposite problem at a personal level. A task becomes so big and daunting when considering everything that should be done to take it to completion-- that I put off even starting it. I thought the article title was an exhortation to people like me to change their mindset and get to work -- and forgive themselves for, even target, stopping at 90%. That could be healthy and useful.
- triyambakam 3y ago
  > I thought the article title was an exhortation to people like me to change their mindset and get to work -- and forgive themselves for, even target, stopping at 90%. I thought that is what it would be, too. And I agree, that is a healthy approach if a task seems too big to complete. Just focus on the minimum viable outcome, and be sure to break things down into small pieces, minimum viable outcomes in their own right.
mercurialsolo 3y ago
Done is a hard concept. I would honestly like to understand if the 10% is in reality 10% or more like 80%. Is the project done until it has adoption? Until it finds utility in someone else's workflow? And does it take 10% more work or 80% more because it's adjacent to what you really are good at?
paulcjh 3y ago
In the context of building a product it’s normally best to do some of that final 10% as early as possible. Fail fast, see what works fast. I’ve had so many projects not get to 100% due to things I could have validated in the first 5%
pc86 3y ago
There's a saying the homebuilt aircraft community - 90% done, 90% to go. The last 10% always takes the longest, and especially for stuff like side projects as a developer, a lot of times it's the 10% you want to do the least so it feels like it takes 10x longer than it actually does.
Brian_K_White 3y ago
Why must I care about any of those things besides maybe a long tail of natural at-will refinement? I don't, and as far as I can tell that's fine. This seems somehow unbalanced. If someone started sending companywide emails summarizing their random projects I would start sending companywide emails saying how I cleaned the microwave in the break room.
welder 3y ago
TLDR: Marketing, QA, and roadmapping are often forgotten when finishing the "on-paper" deliverables of projects. ... I should save time and get ChatGPT to summarize articles.
simonw 3y ago
I've started to consider "commit to writing about it" as the price I have to pay for giving into the lure of another project. It's one of the main reasons I publish so much content on https://simonwillison.net/ https://simonwillison.net/ and https://til.simonwillison.net https://til.simonwillison.net A project with a published write-up unlocks so much more value than one which you complete without giving others a chance of understanding what you built. I've maintained internal blogs (sometimes just a Slack channel or Confluence area) at previous employers for this purpose too.
- marginalia_nu 3y ago
  Yeah. I also find a side benefit of writing about what you're doing (or talking about it) other than visibility and education is that it makes you understand it better as well in a very tangible way.
- freshbakedbread 3y ago
  Im interested to learn more about the internal blogs you set up at previous employers. Do employees use it to write about their ongoing projects? Thanks for sharing!
  - simonw 3y ago
    I've mostly tried to lead by example: I start an internal blog, write about my projects and hope that others will follow my need and start their own. I've not had a great deal of success with encouraging others to start doing this, but I still find that the impact my own work has within the company is greatly improved if I have somewhere that I can write about it. I don't expect others to actually read my internal blog on an ongoing basis, but I get a great deal of value out of being able to send links to posts on it to people. I wrote up a big essay about how to use our internal analytics tool once, for example, and shared that with anyone who asked how that thing worked. I've used a few different mechanisms for these: - A Slack channel. Free to setup, anyone who wants to follow along can join the channel. - A confluence blog - confluence has a "blog" feature which you can just start using. - An organization private GitHub repo full of markdown files. I did eventually publish the internal blog posts I wrote at one organization (an organization which has since shut down) - I shared those here: https://simonwillison.net/series/vaccinateca/ https://simonwillison.net/series/vaccinateca/
yakkomajuri 3y ago
Some time ago there was a post on here about not putting projects out to the world. A lot of devs in the comments shared their stories about projects dying out because they weren't 100% ready. I share the same sentiment. A lot of it comes from this - wanting to be at 100%. And as some people here have pointed out, the last 10% takes probably just as much time/energy as the first 90. So yeah, it's a tradeoff. There are definitely a lot of areas where the last 10% matters a lot, and is the differential between successful and mediocre companies for example. But, in a lot of cases, 90% is just fine - I'd rather have 90% and live than strive for 100% and have the thing stay in the closet.
- perlgeek 3y ago
  Publish early, publish often. Put the code on github when there's something to look at. Write your blog posts as soon as you have something usable. Tell your colleagues to use it as soon as it brings them value. Do what OP calls "the last 10%" continually while doing the rest, then you don't stand before the false dichotomy of stopping at 90% or not.
EGreg 3y ago
After the first 90% there is the other 90%. People underestimate how much time that takes. It requires partners and skills you have not necessarily honed. The actual answer is get partners motivated enough to do the rest.
romesmoke 3y ago
I'd prefer a "going beyond 100%" formulation. The concrete deliverables are the end goal. Anything extra is welcome, of course, but modern life doesn't leave room for anything extra. Aspire towards what the author frames as "100%" and be prepared for disappointment.
angarg12 3y ago
> Broadcast an email with the takeaways so that the rest of your organization knows about it. Funny that OP mentions this as part of the last 10% because the experience in my company is the complete opposite. People tend to send self-congratulatory emails before a project is even 90% done. This creates perversive incentives. Some people who want to game the system will stay around just long enough to get visibility, credit, and virtual pats on the back. Then they'll move on to another project that they can capitalize, either not finishing the rest, or dumping it into another unsuspecting soul.
alex-mohr 3y ago
See also Chris Lema's "Done Done" essays[0] and book[1] for more about the value of taking things to finished. [0]: https://chrislema.com/a-done-done-culture-habit-one/ https://chrislema.com/a-done-done-culture-habit-one/ [1]: https://www.amazon.com/Creating-Done-Culture-Habits-Performers-ebook/dp/B009VV0CTI https://www.amazon.com/Creating-Done-Culture-Habits-Performe...
didgetmaster 3y ago
The world is flooded with software where the developers stopped at 90% (or even less than 80%). There is little or no documentation. Very little testing was done so anything but the most simple input can reveal bugs. The UI is convoluted and not intuitive. The list goes on... Software is almost never finished. You can always make an improvement to just about anything, but it should at least meet some minimum threshold.
zgin4679 3y ago
TL;DR as summarized by Ted Turner: “Early to bed, early to rise, work like hell and advertise.”
pizza 3y ago
Changing the intended user from the developer to an external client is a really high g-force maneuver and past a certain level of complexity it’s likely to flameout the developer without a reliable support system.
pgpta 3y ago
I've seen the complete opposite of this in Big Tech. 1. People notoriously lobby for greenfield projects. Obviously all the viable products are already built, they don't want to make research moonshots (bad for quick promos). So, they create do weak market research and justify their 1000th CRM project. 2. Once it's approved, the building is done by lowly SDEs. Meanwhile, managers and senior engineers are busy in Self-congratulatory emails, giving presentations and taking as much credit as they can. 3. In Bad Big Techs, the building part is fast-tracked so that upper-echelon can gather more kudos per quarter. This creates the toxic WLB scenario. 4. The product launches and gets initial users mainly due to large marketing push. Now the biggest task in hand is operational tasks such as handling outages, security risks etc. These are low visibility unthanked tasks. 5. The PMs/Managers/Senior Engineers don't believe their own product will actually get traction. They jump to another project after receiving virtual medals/promos and the cycle starts anew. In the whole process, the top brass has done nothing but evangelize themselves. The only real skill they've demonstrated is convincing their seniors/ teaching their seniors to convince their seniors to greenlight the project.
- hkon 3y ago
  I think point number 2 is what the author is talking about. Honestly I don't mind others doing what they want to make themselves seem important. I will move on to the next task at hand. It's not like it's going to make a difference for me either way.
hkon 3y ago
I will gladly stop at what the authors defines to be 90%. Someone else can do the tasks outlined by the author. I will work on solving the next problem in my area of expertise.
hamdouni 3y ago
It's more like Pareto 80/20 than 90/10. Maybe 50/50 as the rest to be done is out of my league. Half done is what I'll think when coding is finished.
pedalpete 3y ago
For an interesting perspective on this, I'd recommend Ryan Holiday's book Perennial Seller. In it he describes the process of both his writing and his marketing. You're not done writing when the chapter is written, that is just the start. All the editing is the time consuming part. The marketing needs to be part of the plan before the writing starts. It isn't "write a book and then sell it". He's continuously building his audience, trying to figure out what to write, writing, editing, "selling" (not actively selling, but doing the work to get feedback or get people excited about what he is writing). Repeat, repeat, repeat.
esafak 3y ago
If you have a product in a competitive market that last 10% of polish could be what sells it.
EconomicsDense 3y ago
[dead]
lobocinza 3y ago
There will always be something to do. 10% can expand to be more work than the initial 90%.

349 points by alexmolas 3y ago

if you create a project, create it as if people would use it, not to keep it in github repo, if you keep your project to yourself the entire effort you had put in the project is completely uselesss.

MattHeard 3y ago

I prefer to stop at 80%.

nsmog767 3y ago

I'm a nontechnical marketer with a senior person who builds internal tools. We very much have this problem. We get it...most of the way there. But without a strong system to distribute it, get feedback, get buy-in, a lot of the work is underutilized.

grumpy_coder 3y ago
I do feel the article isn't clear on what the context is, but it sounds like it is really this sort of corporate 'project' like internal research or tools. And from years of doing these things I think they massively underestimate the 'system' as you put it. This system involves process, culture, rewards and a ton of politics. It has some very unique challenges different from shipping products. Often your total addressable market is one team in the company, so product analogies aren't much help. You really need to gain political power to get buy-in. Or in today's corporate environment just be okay with finishing the task to 90% This system needs to be in place prior, building it isn't 10% tacked on the end of a small project.

huijzer 3y ago

Yes but the problem is that engineering projects tend to consist of two halves. There is the first 90% of the work and there is the second 90% of the work.

huijzer 3y ago
Can we start calling "evangelism" "sales" again, by the way? Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology.
- dragonwriter 3y ago
  > Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology. While both come from religion, an evangelist is not the same thing as a theologian.
  - deleted 3y ago
    [deleted]
- wumms 3y ago
  > evangelist - religion: a person who tries to persuade people to become Christians, often by travelling around and organizing religious meetings - opinions: someone who often talks about how good they think something is, and tries to persuade you to have the same opinion - religion: one of the writers of the four books in the Bible about Jesus Christ https://dictionary.cambridge.org/de/worterbuch/englisch/evangelist https://dictionary.cambridge.org/de/worterbuch/englisch/evan...
  - darkclouds 3y ago
    And yet they omit Lawyers in front of juries and Lexicographers writing the next edition of a dictionary. Is there any logic to this exceptional world?
    - hgsgm 3y ago
      Yes, but it's fuzzy.
      - darkclouds 3y ago

secretcombos 3y ago

Promote as you build is the way to go (if you can). I'm posting my book online, article by article. That way you get real-time feedback as to what works at what doesn't.

marginalia_nu 3y ago
Yeah. I do think there are pitfalls to this though. There's a tendency to want to smooth over problems and mistakes and amplify successes, which also makes the story you are telling pretty boring and artificial. Basically: Let me tell you a story of the time we tried to play golf. We went to the US Open and signed up with our fantastic team of engineers, it wasn't easy and our team had to work long hours to figure it out as we went but thanks to teamwork we struck hole in one every time. We're fantastic at golf, and the audience cheered for our amazing teamwork and leadership success, and Tiger Woods came forward from the crowd to shake our hands and was was very impressed with what we were doing in such short time. Like this story had no downs, it's completely flat and omits any problems and greatly exaggerates the successes. It's also like not far off the median linkedin post about a project in progress. It removes all the things that makes a story compelling. What were the problems? How were they overcome? What were the lessons learned?
- seabass-labrax 3y ago
  The risk to this is that your competitors seize the opportunity to criticise your mistakes as if you're hiding them, even if you wrote about them yourself! As such, one justification for keeping problems secret is that your competitors don't know about them. It's unfortunate, as it stops a lot of good-faith collaboration, where strangers will come and offer support.

nlpalks 3y ago

I was delighted to see this headline and post. The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others: "Find someone that can poke holes in your work, then go address them." The underlying issue is widespread in OSS projects. Increasingly it is all about features (for which those who are paid to "work" on projects are rewarded). Others spend 10x the amount to fix the features or leave the projects or are driven out by the corporate developers.

maccard 3y ago
> The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others: Marketing _is_ real work. Software is only useful if it's being used. Now, it's up to the author (or PO/PM) to define _who_ the users are. If it's an internal team, a slack message to that team's channel saying "hey I made X do y" is marketing, but necessary. Sending a PR to an OSS project is marketing. Updating the docs to show how to use your new thing is marketing.
smitty1e 3y ago
> "Find someone that can poke holes in your work, then go address them." What does "address" them mean? If starting from scratch on a fresh project is the easiest way to factor out the design flaw at the heart of my whoopsie, does that count as addressing the problem at a higher level, or blowing off my current whoopsie at 90%?
marginalia_nu 3y ago
> real work This is a a very "programmer" view of the world that the work is when code is being produced, and everything else (especially anything involving people) is not actually productive. You can have enormous impact with that other form of work. Marketing is huge, even for open source projects, even hobby projects. It very directly affects your ability to have an impact on the world. If you do zero marketing, the only impact you have is what you do with your hands, which is not a lot in most cases. Blogging and talking about what I do (=marketing) has opened doors to the extent that I've been able to quit my job and do full time work on what was once a zany hobby project to pass the time during covid isolation. That is, investing some time in marketing in the past let me spend more time "working" on code in the present. The impact has been kind of insane. I've been in The New Yorker because of this. I've done radio interviews. Nothing of this would have happened if I wasn't constantly writing about my projects, constantly making rings on the water stretching farther and farther out. It takes a while to get going and pick up momentum, but the accumulated effect can get very strong. This is marketing. It doesn't have to be shallow and corporate and SEO optimized and pestering users for newsletter subscriptions. It can be authentic and personal... but it's still marketing. If anything, that's the best sort of marketing. I believe what I write, I stick to my principles and I'm not trying to bullshit anyone. That stuff shines through.

ansc 3y ago

You could as easily write: We spent 4 months building a software system, running experiments, writing an academic paper, and submitting it to a journal for publication. So now we are done. The end. Right? Yes! This is what I call stopping at 90%! The remaining 10% is far more difficult to track and often has no clear stopping point. It's often better to skip the last 10% and move on.

alexmolas 3y ago
In my experience this last 10% is the one that differentiates great work from good work. In my team we use to call it "put the bow on the gift". Receiving a well packaged gift makes the difference.
deleted 3y ago
[deleted]

Kiro 3y ago

This seems like a non-existent problem in software development. Who has ever felt being done and satisfied with anything? It's always the opposite with an endless backlog of improvements.

poisonborz 3y ago
You are talking about core work. The article is about tangential work, which is just as, if not even more neglected in sw dev. In academia there is at least a tradition of publishing, lecturing and review.
- zelphirkalt 3y ago
  What is core work and what is tangential work?
  - poisonborz 3y ago
    Writing code vs documentation, support, marketing etc.
    - graphviz 3y ago
      This may be a fallacy. It is all connected. Some of the connections are not obvious at first. It's very tempting to create interesting features for your own edification or satisfaction, and leave them nearly undocumented. Years later, kind-hearted strangers discover these in the code and wonder why no one knows about them. Sometimes, it's like code that you just wrote for yourself might as well not even exist for the rest of the world. That's just one facet of this situation.
lvturner 3y ago
Yeah, I see this all the time in my team and this article really succinctly sums it up. It doesn't negate the backlog and the never-ending work - the takeaway here for me is that sometimes you do indeed need to step back and say "Hey me and the team worked really hard on this, come look"

sixthDot 3y ago

Very well known https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule. > What are some common activities to go from 90% to 100%? To the list I'll add - 100% coverage - rewrite it in Rust (ha ha)

winwang 3y ago
- Add dependent types
Karellen 3y ago
I'll admit, to me the point that the author considers 90% is where I consider 99%. IMO, getting from 90% (it works and does the right thing with any valid input) to 99% involves things like - paying down all technical debt - handling malformed or adversarial inputs, including all edge-cases, "reasonably" - better documentation; tutorials, how-tos, explainers, and references. In multiple formats (don't forget your `man` page). - checking for low-hanging perf/memory wins. - interface polish. Is there a long-running operation that might benefit from a progress bar? Or some other indicators which aren't strictly necessary, but would help users model of the state of the program?

amelius 3y ago

I see this a lot with hardware drivers. They tested it once on one system and it worked, then called it a day.

davidgerard 3y ago
MVP, which I keep seeing in practice as stopping as far before 90% as you can.

ChrisMarshallNY 3y ago

90%? More like 50%. Shipping software has a lot of non-coding stuff. We are in the last [coding] lap of a project that has been ongoing for two years. I think we probably still have at least another eight to ten months of stuff ahead of us before we ship.

RyanHamilton 3y ago

If the author has interested you in the possibility of doing the other 10% of work, I would recommend the book "Traction - How any startup can achieve explosive customer growth" by Weinberg and Mares. It actually suggests gaining traction at the same time as developing to ensure a constantfeedback loop. In some cases you will even want to build parts of your product to help you gain traction.I think they even mentioned alternating each week, one week dev, one week marketing, i.e. 50%.

wouldbecouldbe 3y ago
It’s can work but they never talk about the operational & support costs such an approach has, let alone the emotional price

muzani 3y ago

More than 80% of the work is doing the work, the remaining 20% is selling that you did it. More than 80% of the results come from selling it, 20% comes from doing it. It's the case with research, building startups, homework, whatever. If it's not pushed into production and marketed, the value is there, but very tiny. Some people see the results and make the mistake of spending more than 20% of their focus selling it, but nobody respects people who talk a lot but do little.

_xivi 3y ago
What if you don't want to sell it? Does that mean you did 100% or the remaining 10% shift to sth else
taneq 3y ago
About 80% of the doing-the-work bit is figuring out what you're doing and how. There's a lot more work to work than just the bit that we think of as the work.

Tade0 3y ago

Related to this I have a measure that I call "general effectiveness" - mine is 83-86% meaning, when I'm, in my view, perfectly prepared, the outcome is actually closer to that. Every exam I took eventually hovered around that number - assuming I studied. This was particularly visible in math class in high school, where our teacher put emphasis on consistent work. It's a useful model because on one hand if I have a score, I can tell if I did my best and how much of my success can be attributed to individual effort. On the other, when I don't have a score, I at least have a reasonable upper bound on how much was done and how well.

yobbo 3y ago

> ... If no one knows about it or won't give it a chance, then it's as if it never happened. It is rational to stop somewhere between 0% and 100%. There is no guarantee you will find traction in the last 10% or the last 1%, if you get that far. It might have been rational to stop at 17% and instead spent the time and resources on something else. To make an honest and rational decision, there should be go-conditions at several points along the project. Work stops when conditions aren't met.

KnobbleMcKnees 3y ago
A version of what you're describing is the sunk cost fallacy
- dizhn 3y ago
  My familiarity with the fallacy enabled me to quit watching John Wick in the last 10 minutes. 10 minutes saved is not nothing.
  - selimthegrim 3y ago
    You didn’t quit when the dog got killed?
    - dizhn 3y ago
      Come to think of it, I think it was John Wick 2. Bonus site: https://www.doesthedogdie.com/ https://www.doesthedogdie.com/
  - sfink 3y ago
    I wish I had been able to do that. But at least I get to see announcements for John Wick 4 and get a warm fuzzy feeling that I have escaped watching 3 whole movies, and thus have an extra 6 hours in which to do something better in my life with an exceptionally low bar for "better".

_xivi 3y ago

> where as the remaining 10% is far more difficult to track and often has no clear stopping point. The problem isn't that it's difficult to track. It's not even clear what the remaining 10% is, or if it's 10% to begin with. If you asked 10 people what the rest 10% is about, you'll get 10 different answers.

twodave 3y ago

From an academic perspective, sure? I guess? But most things done in the name of academia are for the purpose of learning, so the goals are different. If your goal is to build a PRODUCT this is stupid advice. You really want to stop once your primary use cases go end to end. It doesn't even need to scale. Go make a sale or whatever flavor of "get users" your product needs to be validated. Most products don't get the benefit of being able to stand on their own. Every customer you add comes with their own unique last 10% that you'll need to work on to get them to sign up. So go find out what THOSE requirements are, or you'll end up doing the wrong "last 10%". Oh, and make sure you understand what the client is actually asking for, or you'll end up doing the wrong 10% and losing your next big customer, which can be a super demoralizing experience.

deleted 3y ago

[deleted]

JacobSeated 3y ago

Things rarely reach a 100% and that's okay imo – as long as I am still making progress. It's hard to find time and energy for dedicated work sessions on personal projects with a full time job. Small incremental improvements ftw!

w-m 3y ago

I put a lot of work into doing the last 10% for a project recently, and I'm not convinced yet that I'll be getting anything out of it, other than my own satisfaction. After my colleagues and I got our paper (on real-time depth estimation with an event camera and a laser projector [0]) accepted at a workshop, we could have just dumped the convoluted, messy research code on GitHub and be done with it. For other people to figure it out, if they really cared. But I sat down and completely rewrote all the scaffolding around the presented algorithm, to make for a smooth and fast demo. Wrote up documentation for the implementation, gave it a command line interface, set up a script to reproduce the measurements in the paper with a single execution (downloading the required data and comparing several methods). Broadcast in all channels available to me (institution press release, LinkedIn posts, GitHub awesome list linkings). And I actually brought the demo to the workshop, which wasn't required at all, I could have just presented it as a poster. The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not. Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success. [0]: https://fraunhoferhhi.github.io/X-maps/ https://fraunhoferhhi.github.io/X-maps/

sidmitra 3y ago
There might be people years from now that could benefit from your work. Caring about something and putting it out there is never in vain.
- DoughnutHole 3y ago
  It might not be in vain, but it can often be a poor balancing of priorities. The last 10% can easily require as much work as the first 90% - perfection is expensive. If your reason to perfect something is internal (high personal standards and taking pride in your work) then great - take the opportunity cost in stride and finish something you'll be satisfied with. But if it's external (eg. making it just that bit more impressive to others) I'd say usually your time would be better spent moving on to the next thing.

jongjong 3y ago

It's hard to know why projects didn't get traction. Is it because the documentation is not as good as it could have been? Is it because the marketing was insufficient? There are some projects out there which are similar to some of my projects and which did get traction and they have basically the same level of polish and documentation. I feel like it just comes down to marketing which itself just comes down to social connections. I'm quite certain now that if someone like Elon Musk looked at some of my projects and promoted them, they'd get tons of traction. The user feedback on some of my projects has been very good but it appears that none of my users has been a high-exposure individual. On one of my open source projects which did get a little bit of initial traction, at one point traction slowed down and I was paranoid and thought that the code could be improved more and I reworked a lot of stuff to make it work optimally with Kubernetes. But some years down the line I found out that a significant subset of my users actually preferred how it worked before and were still using the old version. I still think it was a good move because the new architecture is much simpler and more elegant but probably not necessary as it didn't help my project get more traction. Sometimes the only problem is just marketing and social networking and if you're not born at the right place and right time, there's nothing you can do about it.

server_man3000 3y ago

This article just breeds classic toxic work mentality. There is nothing wrong doing 90% of a project. Hell, I’ve learned the most doing just 50-70% of side projects and moving to other ideas faster.

blitz_skull 3y ago

The Pareto Principle would beg to differ. I highly doubt you’re getting the same value out of the remaining 10% that you got out of the first 90%. Or maybe I have it backwards and the 10% is 80% of the value? But no, that makes me uncomfortable considering my pattern of unfinished projects so I’m going to go with my first theory.

drsim 3y ago

I call this the definition of done. It’s when my kids think they’re done with breakfast but haven’t washed their hands. It’s when a PM is done with a feature when it’s deployed to production but its success hasn’t been measured. It’s when I’m done with writing a blog post but haven’t proofread it. Defining done and having stakeholders agree on the definition is how we move forward. Without that, the entropy of work trends to empty busyness.

pachico 3y ago

This is why, at least at work,you need a strict definition of done. A DoD isn't only useful to you and your team but also to the rest of your organisation so that everyone knows that you might still be working on a task/project although you have already finished the most visible part of it. It helps, in general, to manage expectations.

deleted 3y ago

[deleted]

albert_e 3y ago

I have the opposite problem at a personal level. A task becomes so big and daunting when considering everything that should be done to take it to completion-- that I put off even starting it. I thought the article title was an exhortation to people like me to change their mindset and get to work -- and forgive themselves for, even target, stopping at 90%. That could be healthy and useful.

triyambakam 3y ago
> I thought the article title was an exhortation to people like me to change their mindset and get to work -- and forgive themselves for, even target, stopping at 90%. I thought that is what it would be, too. And I agree, that is a healthy approach if a task seems too big to complete. Just focus on the minimum viable outcome, and be sure to break things down into small pieces, minimum viable outcomes in their own right.

mercurialsolo 3y ago

Done is a hard concept. I would honestly like to understand if the 10% is in reality 10% or more like 80%. Is the project done until it has adoption? Until it finds utility in someone else's workflow? And does it take 10% more work or 80% more because it's adjacent to what you really are good at?

paulcjh 3y ago

In the context of building a product it’s normally best to do some of that final 10% as early as possible. Fail fast, see what works fast. I’ve had so many projects not get to 100% due to things I could have validated in the first 5%

pc86 3y ago

There's a saying the homebuilt aircraft community - 90% done, 90% to go. The last 10% always takes the longest, and especially for stuff like side projects as a developer, a lot of times it's the 10% you want to do the least so it feels like it takes 10x longer than it actually does.

Brian_K_White 3y ago

Why must I care about any of those things besides maybe a long tail of natural at-will refinement? I don't, and as far as I can tell that's fine. This seems somehow unbalanced. If someone started sending companywide emails summarizing their random projects I would start sending companywide emails saying how I cleaned the microwave in the break room.

welder 3y ago

TLDR: Marketing, QA, and roadmapping are often forgotten when finishing the "on-paper" deliverables of projects. ... I should save time and get ChatGPT to summarize articles.

simonw 3y ago

I've started to consider "commit to writing about it" as the price I have to pay for giving into the lure of another project. It's one of the main reasons I publish so much content on https://simonwillison.net/ https://simonwillison.net/ and https://til.simonwillison.net https://til.simonwillison.net A project with a published write-up unlocks so much more value than one which you complete without giving others a chance of understanding what you built. I've maintained internal blogs (sometimes just a Slack channel or Confluence area) at previous employers for this purpose too.

marginalia_nu 3y ago
Yeah. I also find a side benefit of writing about what you're doing (or talking about it) other than visibility and education is that it makes you understand it better as well in a very tangible way.
freshbakedbread 3y ago
Im interested to learn more about the internal blogs you set up at previous employers. Do employees use it to write about their ongoing projects? Thanks for sharing!
- simonw 3y ago
  I've mostly tried to lead by example: I start an internal blog, write about my projects and hope that others will follow my need and start their own. I've not had a great deal of success with encouraging others to start doing this, but I still find that the impact my own work has within the company is greatly improved if I have somewhere that I can write about it. I don't expect others to actually read my internal blog on an ongoing basis, but I get a great deal of value out of being able to send links to posts on it to people. I wrote up a big essay about how to use our internal analytics tool once, for example, and shared that with anyone who asked how that thing worked. I've used a few different mechanisms for these: - A Slack channel. Free to setup, anyone who wants to follow along can join the channel. - A confluence blog - confluence has a "blog" feature which you can just start using. - An organization private GitHub repo full of markdown files. I did eventually publish the internal blog posts I wrote at one organization (an organization which has since shut down) - I shared those here: https://simonwillison.net/series/vaccinateca/ https://simonwillison.net/series/vaccinateca/

yakkomajuri 3y ago

Some time ago there was a post on here about not putting projects out to the world. A lot of devs in the comments shared their stories about projects dying out because they weren't 100% ready. I share the same sentiment. A lot of it comes from this - wanting to be at 100%. And as some people here have pointed out, the last 10% takes probably just as much time/energy as the first 90. So yeah, it's a tradeoff. There are definitely a lot of areas where the last 10% matters a lot, and is the differential between successful and mediocre companies for example. But, in a lot of cases, 90% is just fine - I'd rather have 90% and live than strive for 100% and have the thing stay in the closet.

perlgeek 3y ago
Publish early, publish often. Put the code on github when there's something to look at. Write your blog posts as soon as you have something usable. Tell your colleagues to use it as soon as it brings them value. Do what OP calls "the last 10%" continually while doing the rest, then you don't stand before the false dichotomy of stopping at 90% or not.

EGreg 3y ago

After the first 90% there is the other 90%. People underestimate how much time that takes. It requires partners and skills you have not necessarily honed. The actual answer is get partners motivated enough to do the rest.

romesmoke 3y ago

I'd prefer a "going beyond 100%" formulation. The concrete deliverables are the end goal. Anything extra is welcome, of course, but modern life doesn't leave room for anything extra. Aspire towards what the author frames as "100%" and be prepared for disappointment.

angarg12 3y ago

> Broadcast an email with the takeaways so that the rest of your organization knows about it. Funny that OP mentions this as part of the last 10% because the experience in my company is the complete opposite. People tend to send self-congratulatory emails before a project is even 90% done. This creates perversive incentives. Some people who want to game the system will stay around just long enough to get visibility, credit, and virtual pats on the back. Then they'll move on to another project that they can capitalize, either not finishing the rest, or dumping it into another unsuspecting soul.

alex-mohr 3y ago

See also Chris Lema's "Done Done" essays[0] and book[1] for more about the value of taking things to finished. [0]: https://chrislema.com/a-done-done-culture-habit-one/ https://chrislema.com/a-done-done-culture-habit-one/ [1]: https://www.amazon.com/Creating-Done-Culture-Habits-Performers-ebook/dp/B009VV0CTI https://www.amazon.com/Creating-Done-Culture-Habits-Performe...

didgetmaster 3y ago

The world is flooded with software where the developers stopped at 90% (or even less than 80%). There is little or no documentation. Very little testing was done so anything but the most simple input can reveal bugs. The UI is convoluted and not intuitive. The list goes on... Software is almost never finished. You can always make an improvement to just about anything, but it should at least meet some minimum threshold.

zgin4679 3y ago

TL;DR as summarized by Ted Turner: “Early to bed, early to rise, work like hell and advertise.”

pizza 3y ago

Changing the intended user from the developer to an external client is a really high g-force maneuver and past a certain level of complexity it’s likely to flameout the developer without a reliable support system.

pgpta 3y ago

I've seen the complete opposite of this in Big Tech. 1. People notoriously lobby for greenfield projects. Obviously all the viable products are already built, they don't want to make research moonshots (bad for quick promos). So, they create do weak market research and justify their 1000th CRM project. 2. Once it's approved, the building is done by lowly SDEs. Meanwhile, managers and senior engineers are busy in Self-congratulatory emails, giving presentations and taking as much credit as they can. 3. In Bad Big Techs, the building part is fast-tracked so that upper-echelon can gather more kudos per quarter. This creates the toxic WLB scenario. 4. The product launches and gets initial users mainly due to large marketing push. Now the biggest task in hand is operational tasks such as handling outages, security risks etc. These are low visibility unthanked tasks. 5. The PMs/Managers/Senior Engineers don't believe their own product will actually get traction. They jump to another project after receiving virtual medals/promos and the cycle starts anew. In the whole process, the top brass has done nothing but evangelize themselves. The only real skill they've demonstrated is convincing their seniors/ teaching their seniors to convince their seniors to greenlight the project.

hkon 3y ago
I think point number 2 is what the author is talking about. Honestly I don't mind others doing what they want to make themselves seem important. I will move on to the next task at hand. It's not like it's going to make a difference for me either way.

hkon 3y ago

I will gladly stop at what the authors defines to be 90%. Someone else can do the tasks outlined by the author. I will work on solving the next problem in my area of expertise.

hamdouni 3y ago

It's more like Pareto 80/20 than 90/10. Maybe 50/50 as the rest to be done is out of my league. Half done is what I'll think when coding is finished.

pedalpete 3y ago

For an interesting perspective on this, I'd recommend Ryan Holiday's book Perennial Seller. In it he describes the process of both his writing and his marketing. You're not done writing when the chapter is written, that is just the start. All the editing is the time consuming part. The marketing needs to be part of the plan before the writing starts. It isn't "write a book and then sell it". He's continuously building his audience, trying to figure out what to write, writing, editing, "selling" (not actively selling, but doing the work to get feedback or get people excited about what he is writing). Repeat, repeat, repeat.

esafak 3y ago

If you have a product in a competitive market that last 10% of polish could be what sells it.

EconomicsDense 3y ago

[dead]

lobocinza 3y ago

There will always be something to do. 10% can expand to be more work than the initial 90%.