Manifesto for minimalist software engineers (2013)

Well stated. Deep down I’ve known this to be true, but since Pareto’s law is often over used, it’s easy to lose sight of other aspects of reality. This one is often overlooked.

Judgement must be used to understand how these two concepts can apply to a given situation or decision.

Difference between principle and law: https://philosophy.stackexchange.com/a/94475

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

The conflation being at the root of most of what you said is unfortunate: Pareto's law would indeed be a bad law, if it existed.

Yes, I think the world is full of situations where 80% of the payoff comes from 20% of the work.

I'd even be cheeky and say that the Pareto principle applies to about 80% of situations.

Distributions of behavior that are perfectly flat like you suggest might exist, but are less common in large populations or samples. Do we have any names/principles/laws relating to flat distributions in nature or human behavior? I’m curious if you could give some examples of what you’re thinking of, the situations where there’s 0 payoff until all the work is done, and what basis there is for claiming this is equally true and common as varied distributions?

It depends on your perspective. For a lot of those 100% situations, you could think up some high-effort, low-payoff bells and whistles to turn it into a 80%/20% situation.

No "law" of software or business is technically a law in the same rigorous sense that a scientific law is. But that's not why we call them laws and it would be nitpicking to call that out, besides entirely missing the point.

Also, it's actually the Pareto Principle (https://en.wikipedia.org/wiki/Pareto_principle) not "Pareto's Law" but that's also nitpicking.

In both cases I'd say that the authors is getting at the right idea but they haven't really formulated it precisely in their heads.

As such the value is clear to the experienced person with the benefit of many years hindsight but not to the newbie.

Maybe, but the context/requirements change too. For one of your examples, what a web server is desired to do changes with HTTP/2, and that may mean the "last" web server no longer is. But even less drastic/specific things can change desires and requirements; things change, even if hardware doesn't.

I am against a world economy based on mandatory high growth. I am also against new tech, just because something is new. I make exceptions: deep learning applied to real world problems, better theories and implementation for security and privacy, and better online platforms for creating things; for example leanpub for writing and Google Colab for writing and sharing ideas and experiments in ML and DL.

How often are we disappointed when new versions of software seem worse than previous versions?

However, project management loves to mark things as complete, so getting it polished to usual standards is the hardest part.

So it winds up being arguments about whether something is "bad" or "good enough". I mean, that's kind of the whole damn trick, figuring out what is good enough.

It's good to remember that "good enough" has upper as well as lower bands, it's true that perfectionism is not the way to go -- especially because you are usually over-confident in your ability to predict how something will actually turn out under real world use and requirements.

But I also find people insisting "the perfect is the enemy of the good" while trying to do crap. Why bother trying to do better than crap, the perfect is the enemy of the good!

Determining what is "good enough", over the sustainable long haul, is literally the whole trick to software design. At what point you are getting diminishing returns or even counter-productive complexity from trying to polish it further. If it was easy we wouldn't be having these conversations. Slogans still don't make it easy.

I've done over and over without any issues.

In order to work on second step you need two things:

1. A plan (at least a vague one) of how will you execute the second step iteratively (i.e. without rewriting everything from scratch).

2. Actual business need for step 2.

If you aren't able to execute step 2 without the Big Rewrite, then it's on you. Business doesn't want to take these risks.

If your business doesn't need step 2, then what are we complaining about?

I guess the only advice I have is stop treating step 2 as "step". It follows the same Pareto Principle: there's 20% of effort in step 2 which gives 80% of results.

In the software world, yes. The question we should be asking is "Does this product need a touchscreen / app / web interface?" There is no "minimal" way to invoke the efforts of half of the world's FOSS (and other) software developers so that you can have a "beautifully" animated button to dispense coffee (yes, my workplace has a coffee maker with touchscreen, and I hate it).

As a software engineer who personally wrestles with this conundrum on a daily basis, I'd love to set up a "you don't need software" design agency.

Of course it is written for other people, at least if your future self counts as another person. Or is it write-once-never-look-at-it-again code? Then yes, but that's rare.

True to some extent I guess. But in my experience “hipster perfectionism” is also a fantasy.

It’s easy to think that if we make the user experience exactly the users (or in most cases actually some product manager) wants it then we’ll have massive traction. In reality that’s rarely what happens. In many cases I would say nothing at all happens.

As an example I ran the analytics group at a moderately successful startup a few years back. The engineering team put in massive effort in a new release that would be so much more polished and easier to use. But when we looked at the numbers a few months later it was impossible to discern any meaningful change around the deploy date. I didn’t say anything about this to the higher ups of course, and neither did anybody else.

External constraints can be the driving force here - I have a project which involves firmware running on a soft CPU in an FPGA. I'm targetting several different devices, but the project will no longer fit the smallest device if my firmware (code, working RAM and stack combined) goes over 12 kilobytes. In the middle of working on this project I took delivery of a new workgroup printer at work, the remote monitoring software for which was a 1.5 gigabyte download. And apparently we live in a world that sees nothing wrong with that!

Failing fast and iterating is absolutely important to make sure you're building what your users actually need. I've found that what users want/need and what they think they want can be very different.