Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Last 1%

jaredramsey.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: The Last 1%

#61

Post by t-writescode »

huganabaga wrote: post #54
t-writescode wrote: post #10

Earlier quoted context omitted.

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.

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

There are several forms of documentation:

  * comments in code
  * team-based comments
  * project design docs
  * knowledge-base articles for handling on-call rotation around feature
  * how-to guides for customers
Each of these has a different cost and a different direct/external usefulness. I absolutely believe in good documentation and I absolutely believe that it's valuable. It does not negate the extra cost of including these forms of documentation - especially the "not-in-code" documentation.

Re: The Last 1%

#62

Post by huganabaga »

t-writescode wrote: post #61
huganabaga wrote: post #54

Earlier quoted context omitted.

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

There are several forms of documentation: * comments in code * team-based comments * project design docs * knowledge-base articles for handling on-call rotation around feature * how-to guides for customers Each of these has a different cost and a different direct/external usefulness. I absolutely believe in good documentation and I absolutely believe that it's valuable. It does not negate the extra cost of including…

Of course they "cost". But the issue is the mindset that they are "extra". They are not. They are an integral part to professional software engineering. You can't take them away without moving from a professional craft into some hobby hack.

When developing medicine you wouldn't consider safety studies as "extra". When you fly an airplane then the take off checklist is not "extra". Arguing that automated test suites or documentation are just "extra" on top of making software and could be skipped is similar to arguing that you could fly a plane without any checklists or releasing medicine to the public without evaluating its safety. That's just unprofessional nonsense.

Re: The Last 1%

#64

Post by ssrc »

reidjs wrote: post #49
lumost wrote: post #8

Earlier quoted context omitted.

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

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

For the tooling part, I suppose it's something like a "golden path"[1] where you have predefined templates from which the developers may choose the most appropriate for their problem.

[1] https://cloud.redhat.com/blog/designing-golden-paths

Re: The Last 1%

#65

Post by hackernewds »

coldtea wrote: post #22

> 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 t…

> 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

Re: The Last 1%

#66

Post by hackernewds »

t-writescode wrote: post #2

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

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

Re: The Last 1%

#67

Post by ergocoder »

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.

Re: The Last 1%

#68

Post by bradley13 »

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.

Re: The Last 1%

#69

Post by lazyasciiart »

vasco wrote: post #26
bluefishinit wrote: post #19

Earlier quoted context omitted.

Everything from what gets tracked to how the data gets interpreted. It also can put a target on certain growth areas that will attract the more "ambitious" people from the company. All will try to make the case with the telemetry data. Does more time on a page mean users are more engaged or are they struggling to find out what's going on? Depends on which product manager can make a better case, probably involving eve…

I agree with you in spirit but you have to realize that every developer and designer pairs will think they are the ones that know what they are doing and should have the trust. I've seen trust be given for periods of years and teams simply wasting time and not meaningfully improving anything. This only works with good product people on board and most product people aren't any good at product.

Saying that you’ll use data to make decisions doesn’t change that - most people can’t tell the difference between meaningful data and random sets of numbers with a headline, so it’s still trust awarded to the most convincing salesman.

Re: The Last 1%

#70

Post by thyrsus »

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.
Post reply on HN