Live data from Hacker News

Tech takes the Pareto principle too far

bobbylox.com

31–40 of 127 posts

Re: Tech takes the Pareto principle too far

#31
There’s a conflation going on here. Pareto can be good engineering—a product that solves 80% of use cases at 20% of the cost is a great efficiency: tax prep software for simple tax returns only; a minimalist photo sharing site with few social features; a phone with a great UI and no user-installable apps.

This gets conflated with products that are 80% reliable across all their tasks (LLMs, brittle software). That makes it difficult for users to rely on the product, because occasionally a failure will happen, and the user can’t build a mental model of what works and doesn’t.

Re: Tech takes the Pareto principle too far

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

[flagged]

Fair point. I could have and should have done better. Sadly the edit window has passed otherwise I would clean up the original. In a sense, this more or less represents the core purpose of an MVP in action. The author might take the same lesson and revisit this essay in light of the feedback here (or just abandon it as a misstep that is not worth the effort to refine). I was sincere in saying that I appreciate the effort to get something out and start a conversation. While I disagree with most of the essay, there is certainly something to be said for striving to produce high quality work in everything we do. An MVP mindset can be an excuse for not holding ourselves to the highest standard (case in point, me posting a thing with half a dozen typos).

Re: Tech takes the Pareto principle too far

#33

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…

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.

Re: Tech takes the Pareto principle too far

#34
post #4

Earlier quoted context omitted.

Please don't post like this. I actually banned you until I double-checked and saw that you're a legit user. Your comments have veered too far in the direction of ideological battle and flamewar. That's not what this site is for, and destroys what it is for. Please veer back. https://news.ycombinator.com/newsguidelines.html

Uhhh why is my comment a flamewar?

I was referring to your comments in general.

Your GP comment wasn't flamewar. But it was quite offtopic and we got complaints about it being unintelligible.

Re: Tech takes the Pareto principle too far

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

[flagged]

Let's not bother with that please. We want curious conversation here. Posting interesting and curious things matters infinitely more than spelling.

Of course it's always fine to ask for clarification when necessary.

Re: Tech takes the Pareto principle too far

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

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 omitting half the existing features to much chagrin).

Re: Tech takes the Pareto principle too far

#37
post #33

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…

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.

Go into database internals, or flight control, or hard real time operating systems. Those are areas where it has to work.

Re: Tech takes the Pareto principle too far

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

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.

The most equivalent milestone to MVP in games is first playable (FP) or prototype. This is done at first pass/L1/greybox quality.

Vertical slice (VS) is a type of beautiful corner — this is done at production quality.

The purpose of FP is to prove the game loop and that a game is worth producing — that it is viable, or you could say that it has reached the minimum viable state. The purpose of VS is to try out the entire production process and test burndowns, etc.

I can confirm, as someone who has worked in games for decades, that the author understands it correctly.

FP in automotive would be a prototype car, VS in automotive would be the first factory produced car. VS in games often marks the end of pre-production and a shift of priorities from iterating and experimenting to producing bulk content. MVP would be much earlier.

Then in another sense, MVP is already marketable and commercially viable. But a game is that neither at VS nor FP. So if you look at MVP from that perspective, it is not even close to either VS or FP. It would be like somewhere beyond around alpha. In any case, MVP != VS :)

The MVP concept doesn’t work with game production that well because it’s a hit driven industry where most of the costs go into producing the hit. Like in movies, music, TV and book publishing — there are many stages of green-lighting before a product is first made available to the market as going from zero to market is where the bulk of the costs are. Going zero to market MVP as the first green-light check would be quite expensive ($50M for market leading VR/handheld, $100M for market leading console and Windows games minimum spent by the time a game is shown to the players) and risky. So instead, we start green-lighting and reviewing the prototype when <$2M is spent in most cases.

Re: Tech takes the Pareto principle too far

#39
post #33

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…

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.

Re: Tech takes the Pareto principle too far

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

Exactly, the extra effort to complete it is worth it, but it is costly. I think this can be explored in a positive way by selling incomplete things cheaper to the end user while using this money to sustain the development of the last 20%. I think Minecraft is a well known example of applying this model that was fair for both the developers and end users.

While I don't believe Minecraft was the first, it did set the stage for the early access model of development, which fits in great with agile development practices and sustainable practices as the developers can release their vertical slice or MVP, then continue development and correct it based on customer feedback. One example of that is Factorio that has been in development for over a decade now, providing value (enjoyable gameplay) the whole time while also getting continuous development and new features as well as a huge and lively modding community, which in itself translated into their major DLC (based on one of the bigger and more popular mods, they hired the developer and probably a few more people from the modding community).

They're "finished" with it now though, after years of weekly updates they've gone quiet in November. But, they're also working on a new game.

Post reply on HN