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

Tech takes the Pareto principle too far

bobbylox.com

Post reply on HN
Print view View original

71–80 of 127 posts

Re: Tech takes the Pareto principle too far

#71

Post by WJW »

Cthulhu_ wrote: post #39
mrkeen wrote: post #33

Earlier quoted context omitted.

I always wonder where the devs come from who end up doing important work. Seniority doesn't mean anything if a dev's 20 years has been spent flinging crap over the wall and then wondering how to keep up with all the support tickets being filed. How does one get onto the "software is suppose to work" career track.

> How does one get onto the "software is suppose to work" career track. Boring companies that have had IT for a long time; industries like government, taxes, energy, administration, CRM, insurance, pensions, banking, etc. You won't get recruiters knocking on your doorstep to come and work for those though, and you'll possibly be working with 10+ year old tech and development practices.

10+ year old development means practices like scrum and agile? Or do you mean 10+ year old tech like Golang and Rust? /s of course but I think you need to calibrate your level of "old" :)

Re: Tech takes the Pareto principle too far

#72

Post by hnthrow90348765 »

LawrenceKerr wrote: post #67
euroderf wrote: post #55

Earlier quoted context omitted.

> the last 80% give us something much more that isn’t quantified: The feeling of having completed something of value, and having done it properly, carries an inherent value that surpasses the last 20% output. It is unquantifiable and priceless. This is when work or products become timeless and truly valuable. Not to mention that feeling of satisfaction and completeness of taking an accomplishment to that level. This…

> Capitalism generates crap software. As opposed to state-funded software development, which is renowed for its high quality and innovation.

You'd see a lot more from both sides if the motivations were there. The motivation in safety critical stuff is not killing people. It won't matter if I get a boring CRUD app feature to near perfection, I make the same regardless, and that's true in private companies and government.

I think the safety critical developers maybe have some deep itch to scratch and compensation is way less important to them (otherwise they should be making millions in salary given the stakes), but we don't need to use that bar for every developer or product.

But maybe AI will commoditize all of the old boring CRUD apps and those kinds developers are only worth $20-30/hr.

Re: Tech takes the Pareto principle too far

#73

Post by DrScientist »

shswkna wrote: post #2

In terms of economics and utility, the last 80% of effort produces 20% of the result. But the last 80% give us something much more that isn’t quantified: The feeling of having completed something of value, and having done it properly, carries an inherent value that surpasses the last 20% output. It is unquantifiable and priceless. This is when work or products become timeless and truly valuable. Not to mention that f…

I'd actually flip it around - in a crowded market the last 80% of work on those 20% features is what makes you stand out.

It's the detail, the little touches, that result in the comparative advantage in the market - not the shared 80% ( most chairs have 4 legs, seat and back - that 80% isn't what you compete on ).

Re: Tech takes the Pareto principle too far

#74

Post by philipwhiuk »

evv555 wrote: post #65
globular-toast wrote: post #43

Earlier quoted context omitted.

> Video Games are generally competing for a slice of a large preexisting market. The test is whether it can compete against existing products. A new to the world software start up is trying to serve a need that is currently unserved. I feel like it's completely the opposite. A new game doesn't need to "replace" old games. People have played those games. It only needs to be new and good enough to get people's attentio…

I don't really disagree but if you look at the most played games on steam many of them are now old. There's a growing inventory of games that are turning into classics.

Not really. Prior classics age out at roughly the same rate.

Re: Tech takes the Pareto principle too far

#75

Post by Gravityloss »

Xelbair wrote: post #62
Gravityloss wrote: post #59

Earlier quoted context omitted.

That's the point. It's not supposed to be technologically novel, at least at start. It's a new business. The innovation is in the business part. When we were in Rome and exited the Colosseum, it started raining. Some random dude walked to us and sold us an umbrella. Great business, both of us were better off.

It's more akin to someone giving you an umbrella subscription(if it rains more than twice this year I'll save money!), killing our all the competition with dumping prices by running on loss for years, and then hiking up the prices, while also tracking you and telling every food vendor your favorite food so they can prepare a greeter for you. if you think that's a sustainable model, and is good for society then you do…

I don't like those predatory businesses. I think many games are like that nowadays. But not all businesses are like that. I think a game like Factorio is honest and respectable. It doesn't have any subscription models, you buy it once and own it forever. Technologically, AFAIK, it's using old fashioned technology (Allegro was started in 1990). The innovation is in the gameplay part.

Re: Tech takes the Pareto principle too far

#76

Post by prmph »

knowhy wrote: post #27

> I think that the Pareto Principle is technically true in a lot of fields, but I also feel our society would be a lot better off if we didn’t know about it. I doubt that. From what I understand Vilfredo Pareto introduced it to describe the existing allocation of wealth in Italy on the brink of fascism. He claimed that the crops in his garden followed this principle. I highly doubt that that can be replicated. Ever s…

https://en.wikipedia.org/wiki/Pareto_principle#Mathematical_...

Re: Tech takes the Pareto principle too far

#77

Post by dartos »

blululu wrote: post #9

While I appreciate that the author put in the time and effort to write this, I have to say that I disagree with pretty much all of this. Beyond quibbling about specific points, the MVP and the Vertical Slice are functionally similar they totally different in their purpose. Video Games are generally competing for a slice of a large preexisting market. The test is whether it can compete against existing products. A new…

To quibble a bit, I don’t think that magic leap one released as complete products.

Magic leap had like a 30 degree FOV and no software. It was a dev kit, literally. The consumer version was never released IIRC

Also, I don’t think you argued against the main thesis which is something like “startup land is too good at the first 80% of a product, but not the latter 20%”

That rings true for me. Our industry is not known for robustness and quality. There is robust and high quality software out there, but most of it is not.

Re: Tech takes the Pareto principle too far

#78

Post by mattbrewsbytes »

For building software that is your basic web application/SaaS an important part of agile processes, including an MVP, is you build the minimum to get the product out there with lower priority features in a backlog. The idea behind vertical slices in traditional software development (not games) is you have a testable slice of software that can be shipped.

A major benefit of iterative development is you may have features sitting in a backlog that keep getting pushed aside for higher priority features that you aren't expending software development and testing resources on those features. Contrast that with a waterfall approach where an entire product is designed up front, requirements documented and then built. The product likely ends up with features that are not important and rarely used.

Iterative development, or agile, processes are not the best process for every project. You definitely want high risk projects like nuclear power plant control software to use a waterfall approach to ensure safety.

Re: Tech takes the Pareto principle too far

#79

Post by goldfishgold »

froddd wrote: post #22
bigmattystyles wrote: post #12

I feel like every concept can be taken too far or is expected to perfectly encapsulate every situation. The few principles I live by are vague to avoid that predicament- 1. Don't let the perfect be the enemy of the good 2. Under promise, over deliver 3. Graveyards are full of indispensable men 1 took me a long time to really learn 2 In my case, where I've sucked at estimations, it's really not over deliver, but deliv…

That quote is Georges Clemenceau, not Charles De Gaulle. He was a French politician, but long before De Gaulle.

Not Clemenceau either. https://quoteinvestigator.com/2011/11/21/graveyards-full/?am...

Re: Tech takes the Pareto principle too far

#80

Post by Clubber »

mattbrewsbytes wrote: post #78

For building software that is your basic web application/SaaS an important part of agile processes, including an MVP, is you build the minimum to get the product out there with lower priority features in a backlog. The idea behind vertical slices in traditional software development (not games) is you have a testable slice of software that can be shipped. A major benefit of iterative development is you may have featur…

>Contrast that with a waterfall approach where an entire product is designed up front, requirements documented and then built. The product likely ends up with features that are not important and rarely used.

In software development, waterfall projects were often iterative, though in longer cycles. I'm sure there were some that weren't but each version is essentially a waterfall iteration. For example, way back when, we would do 2 major releases and 2 patch releases every year, so our iterations were 3 months. Keep in mind this was software that we cut onto CD's and shipped out.

The benefit of waterfall is that biz is required to think about the project as a whole instead of a wishlist. Sometimes with agile, you end up with a Homermobile because the biz isn't forced to think of everything at once. Both have plusses and minuses.

Post reply on HN