Live data from Hacker News

Tech takes the Pareto principle too far

bobbylox.com

91–100 of 127 posts

Re: Tech takes the Pareto principle too far

#91

Software that is critical is not build like that. Medical device control software is not build like that, drone flight control is not build like that, power plant safety is not build like that. The problem that I noticed in the recent years is: People see the fast dev cycles for non critical software and think they can replicate it in areas where it really does not fit. I guess that’s how we ended up with Teslas self…

> Medical device control software is not build like that > power plant safety is not build like that.

Agreed.

> drone flight control is not build like that

You obviously haven't been working in the drone industry, have you? Just a guess :-).

Re: Tech takes the Pareto principle too far

#92

Earlier quoted context omitted.

I think it’s also worth mentioning that the author fundamentally misunderstands a MVP. A vertical slice video game presentation _is_ a kind of MVP, and there are tons of anecdotes e.g. from the E3 that tell us just how minimal these can be. MVPs take different shapes and forms, a polished but limited video game level is no different than a polished landing page with functionality limited to e.g. sign up.

I'd argue that an MVP is a minimal game with limited features - say, a platform game where you can walk and jump and finish the game, whereas a vertical slice is the complete experience, walk, jump, collect items, fight, achievements, etc, but the story is just a concept and there's only one level. In other software, MVP is what you can go live with to all of your customers (often replacing something existing and omi…

I think this is a better comparison than what the article gives. I do think it's not quite necessary to go live to all customers to be an MVP, however. Functionality that requires manual input from the company to make it work might be a reasonable MVP but not viable to go to everyone. It lets you validate what you're doing works, the customer is none the wiser that there's smoke and mirrors, but nonetheless that smoke and mirrors is there.

Re: Tech takes the Pareto principle too far

#93

Earlier quoted context omitted.

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

> and compensation is way less important to them (otherwise they should be making millions in salary given the stakes)

I think I disagree. Doing safety critical does not mean you work 1000x more. Just that you put more care into what you do (you focus on safety vs productivity), have audits and actual processes to ensure quality.

Re: Tech takes the Pareto principle too far

#94

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.

NASA is a counterpoint.

If they actually have resources, the government is capable of good work. But when it is done on the cheap you don’t get the best work. Whether it’s from underfunding the particular agency, or when they have to outsource to private contractors (often by law the lowest bidder). Don’t know how that fits into the capitalist/state-funded matrix.

Re: Tech takes the Pareto principle too far

#95
post #62

Earlier quoted context omitted.

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.

the issue is that Factorio sells you a product. outright.

and they are an outlier.

Re: Tech takes the Pareto principle too far

#96
post #22

Earlier quoted context omitted.

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

That’s a rabbit hole level of interesting! Thanks for sharing!

Re: Tech takes the Pareto principle too far

#97
post #71

Earlier quoted context omitted.

> 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" :)

React included

Re: Tech takes the Pareto principle too far

#98
You may or may not have to finish the last 20%. Since the whole article is based on the premise that you have to, it fails for me.

There are attributes of your project that are table stakes (absolutely required to compete) and there are regulatory or safety requirements. You need all those to ship.

However, everything else is “value” or even just “perceived value” and it is up to your customer which ones “you have to do””.

Let’s put the 80/20 rule another way. If I can get 8 out of 10 features in 20% of the time, it makes sense to do those 8 ( assuming they all have at least some value ).

But what do I do with the 80% of the effort that it would take to get the last two features?

The answer is opportunity cost. What could I do with that time instead? Put another way, what am I NOT going to be able to accomplish because I chose to add those last two features?

If the answer is that I have other features that customers value more, I should do those instead. If I have a backlog of features that all take the same effort as the first 8. I can do 32 of them in the time it would take to deliver the original 2!!

The statement was made that “customers do not like to use 80% of a website”.

If I read this article, maybe I implement the full 10 original features. If I embrace 80/20, maybe I implement 40 instead. Hey look, the “just do 100%” approach resulted in a website with 25% as many features as 80/20. If “customers do not like 80 percent of a website”, they are probably even less happy with 25%. Right?

Now, not all features have the same value. So, the math is not as simple as above. But, in my view, this is the right way to think about 80/20. The perfect is the enemy of the good.

So that tue perfectionists can hate me even more, the same is true “within” features (or whatever other axis you are evaluating). Sometimes customers “expect” or even “demand” features they do not really use. Compliance is a an example. Or stuff that used to matter in a product category (and is still used as a filter) not really does not anymore. You can get a lot of value in your product by adding this stuff, but it is a waste of resources to “do it right” or match every competitor like for like. You may find again that you get essentially all the market success “value” from doing some fraction of the work. Note, I am not saying to ship stuff that is buggy or stuff that does not really work. If that is what you think I am saying, you misunderstand. A shorter version may to say “build what your customers will actually use and not much more”.

What you really want to spend your time on is the stuff that excites people, that differentiates your offering, and takes “relatively” little effort to execute. That is probably not “the last 20%”, most of the time.

Re: Tech takes the Pareto principle too far

#99
post #58

What if we come to a point where even the investors don't care if you can finish a product at all? If the pitch is good enough and they think you can bring in more investors down the road, they will get back their money at a higher evaluation anyway. This would actually explain why so many startups fail – nobody cared for them to succeed anyway, because the initial investors got rich even without there being a produc…

That just means the investors are your real customer.

Re: Tech takes the Pareto principle too far

#100
post #96

Earlier quoted context omitted.

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

That’s a rabbit hole level of interesting! Thanks for sharing!

It's why I come to HN honestly
Post reply on HN