You think that the world is full of situations where 80% of the payoff comes from 20% of the work/complexity/whatever?
I tell you that, equally, the world is full of situations where you get 0% of the payoff unless you've done 100% of the work.
That latter observation is just as true as the former, but it won't make anyone into a best-selling business book author or motivational speaker, as it doesn't help with cognitive dissonance reduction when reflecting upon laziness and ineptitude, as Pareto's law does.
The Pareto Principle is just a kind of byproduct of variation in distributions, it may fall naturally out of a normal distribution and/or a Pareto distribution (https://en.wikipedia.org/wiki/Pareto_distribution) and/or Zipf’s law (https://en.wikipedia.org/wiki/Zipf%27s_law), which are all in fact very common in reality, and why the Pareto thing is frequently approximately correct has been observed by many.
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?
> 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
Not op, but surgery strikes me as an example where there's effectively 0 pay-off until you finish everything. I personally wouldn't want the surgeon to sack it off without sewing me back up.
It surely depends on exactly what surgery we’re talking about, but surgery has lots and lots of known variation. Open brain and heart surgery might be good examples of what you’re talking about, but surgery in general is one of the best examples of non-flat distributions with non-binary outcomes. Some surgeries can be abandoned in the middle without stitching the patient, and some people will survive even if most die. Heard a fun podcast just yesterday about fistulated stomachs and the stories of a couple of different people who’ve had them. Surgeons can do a mediocre job stitching and fail to clean everything and there will be a mix of outcomes. They can do a perfect job, and most people will live, but still a few will die anyway.
Thing is, the Pareto principle is not so very useful for a SW engineer. It's merely a mathematical fact. If we focus on the 80 percent that only takes an easy peasy 20 percent of effort, there's no product to deliver. The devil is in the details, details we need.
The minimum viable product concept comes to mind. You don't have a product until you invest the effort required to pass the minimum threshold.
Another example I can think of is escape velocity. I'd venture that the principle you're asking for is "phase change", where a threshold gates a drastic change in behavior.
Isn’t MVP the canonical example of attempting to get some payout while specifically not doing all the work? It is by definition unfinished, and so not doing all the work yet. And the idea is to hit the threshold yeah, but what makes a product minimally viable is notoriously murky and difficult to pin down. “Viable” is pretty much always a subjective metric, it depends on your financial situation and runway. From experience with my own startup, there absolutely was a distribution of behaviors for different MVP effort levels, and the product was never 100% done, but we had paying customers, and doing more of the right kind of work increased the number of paying customers.
Phase change in physics certainly is an example of a narrow peaky distribution, I’m just not sure how often that kind of distribution is a reality for human behavior, which is what the top comment was reacting and referring to. I can think of a few and was just arguing they exist in another thread elsewhere when it comes to pricing and consumption for scarce-resource high-demand economics. So they’re out there, but I’d be pretty hard-pressed to agree that these are common enough to make claims that they’re equal to distributions with lots of variation. It feels like the top comment was making an assumption, arguing that the Pareto principle is a made-up idea that’s just as common as other made-up ideas, but that’s not really true.
> I tell you that, equally, the world is full of situations where you get 0% of the payoff unless you've done 100% of the work.
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.
Oh, optimizing for promotions (or $$ generally) and optimizing for doing a good job are frequently not the same optimization. Beginning with your choice of where to work and going on from there.
> …the world is full of situations where you get 0% of the payoff unless you've done 100% of the work.
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.
A better made up law is that, given a complex enough product, simplicity is inversely proportional to the underlying complexity. An Airbus A380 is a long shaft with windows and wings, etc. This only applies to non brutalist design though.
Also you can make software that does what you need it to do, but feels bad to use because it is not polished because that 20% was not deemed important.
Because if you "waste" a week writing something yourself, nice & lean, you'll be told you've fallen for NIH and probably YAGNI as well, and get your hand slapped. But if you introduce a 3,500-strong dependency tree that'll waste a person-month spread across the team, over a year, plus make the product perform worse and waste god-knows how many person years for your users, to do the same thing... nobody complains as long as whatever you imported has lots of github stars and (ideally) looks good on a résumé.
Repeat for several decisions and soon you have tens of thousands of deps.
I have solved this by refusing to use anything involving node or npm. We had one project kick off with that and it was a lesson in supply chain attacks within a week.
Totally agree. Usually to achieve a KISS state you need a few iterations and refactors to understand clearly the perimeter, objectives, constraints, etc. It is dedication, constant feedback and utmost important: egoless engineering. Usually it pays off when you refactor something by removing hundreds or thousands of LoC and your whole test suite is still all green
Most of these are the sort of "common sense" things you'd get with experience, and I mostly agree with the ideas behind this.
Where we fail as a craft though seems to be in passing on this information to those not yet convinced.
Inter-generational transfer of robust best practices might be fundamentally intractable since often worse practices (pushing featurea over solving technical debt, adding needless complexity and bad abstractions) actually pay well. At the same time, it's not like we're putting in too much effort into this.
I think that's largely the fault of the medium/way the message is crafted. This looks like it aped the agile manifesto which almost went out of its way to be unactionable and vague.
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.
When considering killing the baby, also be aware that complex systems that work, almost always evolve from simple systems that work. A complex system can rarely be developed from the ground up (i.e. via a rewrite). One may then interpret the above maxim as "kill your code while it's still a baby, not once it reaches adulthood".
I think what made this work for us at work is that we (maybe accidentally) made refactoring very cheap and easy. We write almost entirely integration tests that only interact w/ the UI, so not much about the tests is tied to our architecture (instead they're coupled to the UI). The tests run slower than typical highly optimized unit tests of course, but the trade-off is that we can refactor things without breaking the validation that everything still works. This then makes continuous improvement a lot easier to realize than I have experienced in the past, since changing our minds is relatively painless.
This is why I like writing end-to-end tests first (and often times the only thing I write). Unit tests come later after I have decided on solid, reusable lower level abstractions. Unittesting to early makes refactoring too hard.
> we can, and inevitably will, write the last software at some point.
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 think this is highly under appreciated. A particular piece of software exists in a technical, social and economic context. If any of these change, it opens up the space for a replacement or a new addition.
Some big changes are desktop to web, web to mobile, single user to multi-user, power user to newbie… and so on.
That was just one example, but the fact that people disagree on it seems enough to be an example of why the a "last webserver ever" would stop being so. But it was just one example. There are things other than hardware changes that make people want something different out of software. Maybe not you, maybe you never change what you want out of software for any reason. if so you are extremely atypical. ¯\_(ツ)_/¯
I don't chase eternal growth, I stop when I see something that is good enough:
So OpenGL (ES) 3, HTTP/1.1, JSON, SMTP, DNS...
But one thing that I have learned is hardware progression (C64 -> Amiga -> PC -> Raspberry 4) and that race is permanently over for humans for eternity.
So we'll see what happens to software!
Finally you can't just throw more energy at a problem, you actually need to write code with limitations in mind again!
I was working in a new book project on Saturday using old and highly optimized tools: LaTeX/TeX and Emacs. I am deeply appreciative of people who maintain and improve these tools, they are not Dead projects by any means.
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?
Funny that this website is anything but minimal. Instead of using fragments for each section (e.g. http://minifesto.org/#prioritize), this site uses some janky JavaScript scrolling behavior that messes up my browser's back button.
Ah, the minimalist software engineer. I usually encounter them in PRs claiming a change is "over-engineered" despite being literally 5 LOC. It's such a comfortable position to label everything you don't understand as complex and unnecessary. Bonus points of you throw in YAGNI and KISS acronyms!
I have a problem with "Perfect is enemy of good". I get the whole thing with iteration and so on, it looks good on paper, but in my experience when it comes to "First do it, then do it right, then do it better" and modern software development methodologies, you are lucky if you even get to work on the second step. And the nastiest projects I've encountered in my career have been all "evolved".
> you are lucky if you even get to work on the second step
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.
> If your business doesn't need step 2, then what are we complaining about?
Hacky, non automated, low quality, not tested, hard to maintain, slow code. Remember, we are at step 1 of "First do it, then do it right, then do it better."
Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do, because they've been focusing on shipping "good enough" crap instead of focusing on the actual "continuous improvement" they claim to do.
> Hacky, non automated, low quality, not tested, hard to maintain, slow code
Have you seen truck drivers complaining they are forced to drive old trucks and not brand new Ferraris?
If low quality code gets shit done, why would company invest into high quality? Delivering goods in Ferraris might be hell of a fun for drivers, but it's a stupid decision for a trucking company.
How confident are you that your high quality will pay off? When exactly will it pay off? How confident are you that your measurement of "high quality" is not biased? How confident are you that your teammate's perception of "high quality" is not just chasing new hype?
> Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do
Sure, and that's why it's your job to prepare for it. Not by creating "high quality" code in advance, but by creating low quality code that is malleable.
> Have you seen truck drivers complaining they are forced to
> drive old trucks and not brand new Ferraris?
No. Where I come from, truck drivers own their own trucks and are pretty happy about them. What they do complain about, however, is people telling them how to do their job.
> Not by creating "high quality" code in advance, but by
> creating low quality code that is malleable.
Nah, I don't think I will. You can have fun maintaining low quality code. I'll just move somewhere else where these instant gratification, feature oriented "minimalist software engineers" are challenged and cannot smear their spaghetti code in whatever they touch.
> Where I come from, truck drivers own their own trucks and are pretty happy about them
And you're free to write your own software in whatever way you want. But when you're working for a business, the end goal of your code is to create value, not to brag to your friends about fancy dependency injection framework that you used.
> I'll just move somewhere else where these instant gratification, feature oriented "minimalist software engineers" are challenged
It's not about instant gratification, it's about building business that can survive in the market. Creating as much value as possible with as little cost and risk as possible, long enough to survive and become profitable.
In fact, it is very far from instant gratification: I have a list of 100 items I personally want to do, and I only get to work on 10-20 of those. But today I'm mature enough to realize that my personal wants can be at odds with business needs.
"Perfect is enemy of good" is just another name for "make it run first, make it run fast next". It doesn't apply cleanly to everything, but if you have a deadline coming up, an acceptable solution which is gonna be polished in the very next iteration is a good compromise, IMHO.
However, project management loves to mark things as complete, so getting it polished to usual standards is the hardest part.
"perfect" is the enemy of "good", but so is "bad". Bad is definitely the enemy of good.
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.
Minimalism is often a fantasy. If you want to make a great product for the end user you often have to much more engineering work in the backend to give the illusion of simplicity. You can click on any link to open a website, but there is a tremendous amount of complexity behind the scenes (DNS, TCP/IP, HTTP, SSL, routing) to make it all work. The abstraction is simple for the user, but complicated in reality. All of these individual technologies can (and perhaps should be) simpler and more minimalistic, but the totality of the stack is inherently complicated because it solves a hard complicated problem.
Suppose you want to make a new graphics app. Do you want users to easily create beautifully typeset documents? Then you'll have to do a ton of schleppy hard work to give the user the option to bend/morph/scale graphics to their taste. A "minimalist" graphics program isn't any good because then the designer won't be able to create what they have in their mind.
Code isn't written for other people. Code is written so the end user ends up with a great product that solves their problems. If you're lucky the code is minimalistic and beautiful, but usually you'll have to struggle through one schleppy problem after another to give users the features and performance they desire.
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.
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.
Absolutely. No way to tell in advance if a big new release is going to work, and it's all too easy to make a product better in 10 unique ways that just don't matter. You can't A/B test yourself out a local maximum, and some point you have to go for a big new release despite the risk.
> Code isn't written for other people. Code is written so the end user ends up with a great product that solves their problems.
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.
Minimalism isn't always about eliminating or avoiding complexity - though sometimes it is; sometimes it's about having the discipline to avoid wastefulness.
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!
Other options were tried and rejected, or aren't viable. Eg, you have this 1.5GB of stuff, what's there? Probably:
1. Graphics and videos. Nice, high res, smooth animations showing how to operate the printer.
2. Frameworks. Because Qt libraries don't come with Windows.
3. Various dependencies
In turn, each of those explodes due to human needs and convenience. Eg, you have an animation that says "Press here" in text. You sell the printer internationally. You'll probably have 20 different versions of it in every supported language.
A large amount of complexity works down to human convenience -- Unicode requires large fonts and complex software
Some is because the platform is what it is. Windows doesn't have a package manager, so it can't pull in libqt5 for you when you try to install an app -- so it has to come with the app.
We've also agreed that every app shall bundle its own dependencies, because DLL hell was really hell, and trying to have one system-wide copy wasn't working.
On the contrary, it seems like you'd have to try very hard to ship 1.5 GiB of software.
For example, Calibre is around 350 MiB. It embeds Qt, Chromium, Python and ICU, is fully localised, and has rather a lot of functionality.
Video content can be fairly large, but a high-quality 1080p encode is around 500 KiB/s. Can you really pack an hour of instructional videos into some printer software?
I can think of a couple ways that you could cross the 1 GiB mark, but none that would involve sane engineering choices or "trying and rejecting" other options.
To be fair, bundling a Java Runtime Environment will give you a decent head start...
Having to ship instructional assets in multiple (human) languages is a fair point, and one I hadn't considered - though in this particular case there are no movies or animations that I've seen.
Most of Dale's points are correct, though - but that doesn't make it a sane state of affairs, and it saddens me that we just accept it with a sense of dejected resignation instead of trying to do better. I had (obviously naively!) expected the the microchip shortage to prompt a massive drive to extract every bit of value from the ones already in service.
I find the idea of a manifesto in software quite off-putting, since it is inherently idealogical. The ideology itself might have redeeming factors, but I think that it is a poor vehicle for conveying ideas. This manifesto is written in the first-person ("There's something I call fixing a bug by sedimentation"), but it is trying to be universal. If this person has opinions on software engineering, why not just voice those as an individual?
Please stop the MVP, fail fast, etc. garbage. It's the stage where winners are made. 99% of projects won't sell themselves and you will only end up with the self-pleasing excuse that your idea was flawed when in reality, you've sucked at marketing.
Bonus: It's 2022 and people are no longer interested in playing with half-baked MVPs. Think twice before skimping on a decent UI, etc. There won't be a second chance to make a first impression.
A MVP and quality product are not mutually exclusive. To me MVP means do a limited set of things and do them very well. UX is of course part of 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.
I find the concept that my ideas are not flawed (and how dare anyone suggest they are) and success is a matter of connections and existing wealth more self pleasing.
Agree with the thought behind these, but the wording is terrible...
"synthesis"? In what context is this word being used?
"clean kipple"? I've never even heard of that word.The first google result for "kipple" is some reference to Blade-Runner!?
Javascript ecosystem from 2013 to today is almost 10 years now, it's a crazy ride. Imagine folks create the whole market out of backbone.js, so much minimalism.
Looks like they applied their recommendations for software development to their manifesto as well. The grammar is definitely not perfect (maybe not even good).
Looking forward to time when that manifesto will be used as excuses for bad design decisions and treated as silver bullet, just like every previous one
You think that the world is full of situations where 80% of the payoff comes from 20% of the work/complexity/whatever?
I tell you that, equally, the world is full of situations where you get 0% of the payoff unless you've done 100% of the work.
That latter observation is just as true as the former, but it won't make anyone into a best-selling business book author or motivational speaker, as it doesn't help with cognitive dissonance reduction when reflecting upon laziness and ineptitude, as Pareto's law does.