Hacker News Reader

>You realize that it was so trivial that there was no need for a library in the first place

Minimalism can bite you, too. We have around 30 microservices written in Go, each one one of them living in their own repository (separate codebases owned by different teams). Initially we followed Go's idiom "a little copying is better than a little dependency". So every team simply was borrowing code snippets from other microservices' codebases without creating a common shared library, because those snippets were "trivial". Then it hit production and we found that under load/diverse user input many of those trivial functions were quite buggy or inefficient with edge cases. Since those functions/classes were copypasted over multiple codebases, now you had to contact owners of 30 repositories and coordinate bugfixing in all of them, which is slow and painful. Now we're back to having a shared library of common functions, because it's well tested and it's easy to fix bugs by just upgrading. Often what seems trivial is not trivial at all.

It sounds like what you described is not minimalism at all, except from the perception of individual teams. From the perspective of the product, your solution is minimalism.

I'd argue that's not minimalism. A lot of the times it relies on the engineer's intuition: is this trivial enough that it can be copied? If as you say those trivial functions were buggy and nobody saw the red flags while copying so many times by so many engineers, then you have an organizational problem.

>If as you say those trivial functions were buggy and nobody saw the red flags while copying so many times by so many engineers, then you have an organizational problem.

If all potential problems with code could be noticed on spot, we wouldn't have the concept of "bugs". Yes, I mentioned minimalism in my post, but I was specifically referring to the idea of copying "trivial" code as opposed to using a dependency.

I was talking about the kind of intuition that while looking at the code you should know whether it's safe to copy it or not, i.e. whether it should be examined closely before copying. From your story, the same class was copied 30 times by that many engineers (?) and it didn't raise any red flags, it means (and I'll be a bit blunt) you have a problem with your hiring process.

Well, not every engineer is experienced enough to immediately notice all potential problems which can arise in production. It worked in microservice A, why won't it work in microservice B? It all comes down to expertise. The average engineer is probably better off relying on a versioned, upgradable dependency maintained by more experienced folks than on copying code snippets here and there.

When things like this happen, it is in 98% because adding dependency is comething organization discourages while copying is without punishment. Discouragement can be you having to defend it in too uncomfortable process or something similar.

This is a great example of dogmatism prevailing in this industry, and the resultant cargo cult programming.

There's a long-standing trend of inflexible dogmatism that's pervasive in software development. If some thought leader, blog or Google/FB/Microsoft/etc said to do something in one way, then things must be done that way.

I once had someone get red in the face and call me stupid because I suggested that hiring more employees to run things after-hours would be preferable to forcing developers to spend their free time working on-call, because apparently Google's SRE bible says that developers must support operations themselves, even if that means they're doing free work in the middle of the night after putting in their 40+ hours a week in. That was unacceptable because Google said so, who cares if employees are leaving in droves and those that remain are spread so thin that their contributions during actual work hours were suffering. Google knows best, we must do what Google says to do, even if that tanks productivity and retention. The company eventually hired teams in different timezones to keep things running 24/7.

>even if that means they're doing free work in the middle of the night after putting in their 40+ hours a week in

We follow this too, but additional work is paid. It kind of makes sense, because developers who own a service can solve a problem faster and with a better solution than someone from a different team, because they know the full context. In practice, I had to work at night only a few times when production was down. If it's not supercritical, it can wait till the morning.

I have no problem with voluntary on-call duty that is both paid handsomely with overtime rates, even for salaried employees, along with bonuses that make sacrificing free time worth it. That's how on-call duty works in many European countries, by law, and in unionized industries and companies here in the US.

The company didn't push for on-call duty at all for our EU developers, because that would cost the company more money for higher rates and bonuses. Instead, on-call duty was the responsibility of US and Canadian workers, because the company didn't have to pay them for the extra burden and loss of free time. EU developers worked on the same products, and could have done on-call duty with us, but that was never on the table for reasons that had nothing to do with developers being familiar with the projects they're supporting. It was all about reducing costs and getting free work out of developers dressed up as "best practices" from Google.

I really hated on-call support last time I had to do it, and we were all already putting in vastly more than 40 hours a week (seriously are there really any developer jobs that are only 40 hours in practice?).

The ridiculous thing was that it was only about a 1 in 10 chance one would get called, but I still couldn't get any sleep on those nights and would rock up even more tired than usual for work the next morning.

The callers would be end-customers from USA so I was always stressed I'd be too blur to answer well right after wake up and give them a bad impression. Didn't help I only understood some parts of the system so would have to muddle through the rest. My spouse wasn't overly impressed by having the phone randomly ringing at 3am either.

Agreed, had similar experiences, and I won't take a role with any type of on-call duty. Thankfully there are a lot of companies out there that aren't trying to cannibalize their employees' free time to cut costs.

> Minimalism can bite you, too. We have around 30 microservices written in Go…

I guess it depends on your idea of minimalism.

To me, having 30 microservices sounds tremendously complex. The minimalist in me would want to see those 30 microservices converge into a single project.

We had a large, complex, spaghetti-driven monolith before the microservices. Aside from a few microservices which support our infrastructure, a microservice usually serves a single subproduct; several subproducts are united under one UI, they only share the user model and communicate via events. I didn't mean our microservice architecture is minimalist (although when viewed alone, a microservice itself is pretty simple), I was giving an example as to why copying code has disadvantages, too, such as once you decide to copy the code instead of using a dependency you are completely on your own, you will miss any new security, performance updates and bugfixes; even supposedly trivial code can be ridden with subtle bugs.

You are right. IMHO there is zero justification for making any application that complex.

Perhaps this is an indication that there should be fewer than 30 microservices and/or less of a focus on "micro"

That’s an odd judgement to make when you don’t know all of the systems and use cases that those services support.

You might have missed the word "Perhaps" at the start?

From a microservices perspective, wouldn't you make a microservices to host that logic instead of copying the code for it everywhere?

And they'll end up with 300 microservices instead of 30.

30 microseervices? Seriously? What on earth is the justification for having that amount of complexity? I have worked with very complex, very large monolith and client/server applications for 25+ years. And I never had trouble maintaining the code or add functionality. My guess is that using microservices was basically an excuse to rewrite the application? And that rewriting it to a new cleanly designed monolith might have been a better choice. Using “advanced” technologies like Modules and Libraries. A friend of mine has taken over a legacy (20+ years) 100+ microservices application. And it is an absolute nightmare. The complexity of building and deploying it is the worst I have ever seen. 10x worse than then worst monolith I have ever worked with. Debugging is a nightmare. Synchronisation issues makes auto testing almost impossible. The only good thing is that all the microservices are written in the same programming language. Imagine if 5+ different languages and build systems were used instead? The complexity would have been out of this world.

> I asked them to create a library (...) I showed them a two-line solution with a single function (...) and nobody liked it. I was ridiculed right there, for not solving the problem "properly".

And did you solved the problem "properly"?

Odds are you did not.

I mean, it's terribly easy to come up with all sorts of two-liners if you just ignore all requirements and constraints, and don't pay attention to usecases.

This is a major problem plaguing software development. Plenty of people act like they have to carry the burden of being the only competent and smart individual in a sea of fools, and proceed to criticize everything that everyone around them does, for the sin of not doing something that exactly matches your personal opinions and tastes.

This is just another potential problem of "overengingeered" libraries: they often try to offer a general solution to a whole set of somewhat related problem, but each individual user may just need one specific problem solved, and the correct solution for this one problem may indeed just be a very simple "two-liner".

Best example are C++ stdlib classes like std::vector. Sometimes you just need a trivial growable array implemented in a few dozen lines of code, but std::vector pulls in roughly 20kloc of code into each compilation unit, and only if you're very lucky the compiler will condense this down to the same few dozen lines of actually needed code (the fabled "zero cost abstraction").

IMHO OOP languages are more prone to this sort of code bloat problem because they require (or at least "expect") to write a lot of "ceremony code" which is entirely unrelated to the actual problem (such as in C++: constructors, destructors, copy-, move-operators, etc etc... and the actually important "two-liner" problem-solving method is completely buried).

Part of this problem is underconstrained requirements. If you do not specify that “a” can’t be zero in “ax2”, it’s reasonable to behave sensibly in that case. One thing is a free designer who states requirements and constraints. Another is an implementer who was given an isolated task and no more details. You have to be either full-defensive or renegotiate edge cases which probably could lead to unnecessary complexity.

> Best example are C++ stdlib classes like std::vector. Sometimes you just need a trivial growable array implemented in a few dozen lines of code, but std::vector pulls in roughly 20kloc of code into each compilation unit, and only if you're very lucky the compiler will condense this down to the same few dozen lines of actually needed code (the fabled "zero cost abstraction").

This is actually a very poor and ill-thought example. C++'s standard template library is expected to provide generic components that are flexible enough to meet practically all conceivable usecases, so that they meet anyone and everyone's needs.

This, obviously, means it supports way more usecases than the naive implementation you can whip out with "a few dozen lines of code".

There are very good reasons why everyone just picks up std::vector over any other implementation, and only extremely rare edge cases (like stuff that sits in the hot path of some games) ever justify using something exotic.

> to meet practically all conceivable usecases

...and that is exactly the fallacy with the C++ stdlib design philosophy, one-size-fits-all classes like std::vector should either be split into several much more specialized classes, or its runtime behaviour should be much more configurable (but ideally both) - in any case there's no justification for pulling in such an enormous amount of code into each compilation unit.

> in any case there's no justification for pulling in such an enormous amount of code into each compilation unit.

Can you specify what exactly your problem with that is? So far you've handwaved at "I don't trust the optimizer to produce good code", but loc is not inherently tied to how many user-facing abstraction layers there are. In fact, you'll find that there's maybe one additional layer of data abstraction in the actual std::vector itself. There's not much to cut through for the optimizer, and in my experience it has zero trouble doing so.

In terms of compilation speed, you pay the frontend cost for those 20 kloc exactly once if you use precompiled headers.

> should either be split into several much more specialized classes

Could you elaborate what "specialized" (or runtime-configurable) versions of std::vector you are thinking of? Just the fact that some people care about exception guarantees, and some people care about move construction, and some people care about custom allocators, and some people care about emplace semantics, and that not all of these are the same people, doesn't mean that it's inherently good to have separate classes for these aspects.

> Can you specify what exactly your problem with that is?

Compile times mainly. This quickly adds up in a C++ project using the stdlib and gets worse with each new C++ version, it's almost at a point now where each stdlib header includes everything else from the stdlib.

> Could you elaborate what "specialized" (or runtime-configurable) versions of std::vector you are thinking of?

First and foremost more control over growth (e.g. when growing is triggered, by how much the memory is grown). More control over what erasing an element means (e.g. whether the remaining elements are required to stay in order, or if the gap can be filled by swapping in the last element). A POD version which is allowed to replace piece-wise memory operations with bulk operations (here I'm actually not sure if optimizers are clever enough to replace many unique moves with a single memmove). An more straightforward way to define an allocator (most importantly, the allocator shouldn't be part of the vector's type signature - not sure if that's what the new polymorphic_allocator in C++17/20 is about though).

...those are just some obvious requirements I had in the past, but I'm sure other people will have different requirements.

It's rather trivial to write your own specialised form of array management, that is both easier to read & debug & also produces less bloat. I've worked at several places where std:: is verboten.

Only some of the people coming onboard never got over the shock of such a rule, but for the most part, all developers embraced the different paradigm. Teams inter operated faster, iterated changes faster, & there were less issues with inter department libraries. Bugs were far fewer.

It really gives you freedom to have complete ownership of your code, rather than 100% relying on boilerplate libraries. I now see std:: as a disempowering limitation to modern development.

Of course, YMMV.

It also makes it easier to work on other platforms, like embedded, where resources are a premium. Writing your own vector & hashmaps then become part of your muscle memory & it's no longer daunting to write a custom allocator.

Good thing about standard libraries is that I don't have to debug them, because they just work.

> Teams inter operated faster, iterated changes faster, & there were less issues with inter department libraries. Bugs were far fewer.

It's hard for me to come up with a scenario where even a single one of these follows from not using the STL. How do you "iterate changes faster" when you re-invent vectors and hashmaps so much that it becomes muscle memory? How does each team writing their own containers mean "teams interoperated faster"? How does the STL cause "issues with inter department libraries", and what bugs were caused by using standard library containers? At which point did you ever have to debug a std::vector?

I'm genuinely interested if you can retell what problems you ran into there. Maybe my creativity is limited, but I'm drawing blanks.

(To be clear, at the scale of Facebook or Google, writing folly or abseil can easily pay off because you can integrate, say, your profiling or debugging tooling more tightly. But that doesn't appear to be what you're alluding to. I'll also concede resource management on embedded devices.)

Actually, i wanted to ask this question to good software engineers.

I once had a coding problem interview where a half of the logic could be handled by an autobalncing tree. I\ve never really used autobalancing trees in real software before, but i knew how to make them from scratch, quickly as RB tree is a very common school problem. I spend twenty minutes choosing between coding one from scratch and picking an already existing solution. I ended up choosing gnl's RB trees, with all the makefile/autoinstall issue that i would have to fix instead. I did not gain any time, really, but i wanted to show i did not suffer the NIH syndrome. Was that a mistake? Should i stay within the stdlib during coding interviews (i don't know if they could run the code, i think the interviewer was running windows)

Depends on the interviewer I guess. Some people will be adamant to use the stdlib as much as possible because they have a war story of how something went terribly wrong by not using the stdlib, others will insist that the stdlib is rubbish because they have a war story of how something went terribly wrong by relying on the stdlib.

The problem is that both are right.

(but jokes aside, I guess that the interviewer is more interested in your ability to solve a problem from scratch instead of you ability to google for an existing solution - even if googling makes a lot of sense in the real world)

I keep alternating between those positions

And I use FreePascal. Its stdlib is vastly larger than the C++ stdlib, but also completely untested/unusable, because no one is using it.

I wrote my own unicode handling functions for everything.

Yesterday I found a new test case, and noticed that my convert utf8 to lowercase function did not handle the Turkish İ correctly (it should turn into two codepoints rather than one for reasons. although I had a check for that symbol, but it was in the wrong branch). And my function had quadratic runtime, so it was also nearly unusable.

So I fixed my function. Then I thought, why am I even writing a convert to lowercase function? FreePascal already has a convert to lowercase function. There is a lesson here, do not write your own functions, you will miss cases.

So I loaded the stdlib Unicode functions to compare my function to their function. And, segmentation fault. Not in the convert to lowercase function, but just loading that Unicode part of the stdlib broke something.

Although while writing this post, I thought, perhaps I test it again, just the convert to lowercase function, without the crashing part. It also fails to handle the İ. And worse, it returns a string that is one byte too large, like a garbage null terminator. There is a lesson here, do not use the stdlib, it is just broken.

Then I compared it to a compare to lowercase function from another library I had included. Twice as fast as even my new fixed function. But it also does not handle the İ symbol. There is a lesson here, do not use other libraries, they do not do what you need them to do.

Sorry for the İ/i I/ı bug. Even modern software in other languages fall to that trap time to time, so probably it's not handled well in other languages either.

I would ask the interviewer and use it as an opportunity to show your knowledge of data structures and your ability to reason about trade-offs and talk through priorities.

I would say something like: "I think a balanced tree, such as an rb-tree, would be useful here for <reasons that make sense given the problem and the properties of rb trees>. I've written rb trees before and think I could write a basic one in 10-15 minutes or I could use <class from the std library, which uses a balanced tree>. Which would you prefer?"

Assuming what you said made sense I would take an interaction like that as a positive signal.

> and only if you're very lucky the compiler will condense this down to the same few dozen lines of actually needed code

The code consists almost entirely of templates and inline functions and every modern C++ compiler will optimize that away. In a release build there is basically no overhead compared to using raw pointers.

I swear I've worked with people who if they were shown FizzBuzzEnterpriseEdition wouldn't be able to see the joke as that's how they naturally write all code.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Things like this:

   static final int INT_1 = 1;

I've actually seen production code with:

   static final string HTTPS = "https";

   static final string COLON = ":";

   static final string SLASH = "/";

When you introduce a typo in a literal you will typically realise at runtime. Referencing a non-existing field won’t make it through compile time. I honestly don’t see the problem with this approach. I would choose better (semantic) names though.

You shouldn't introduce a typo in the int literal "1" or even in the word "https". It should be in your manual memory.

Some say it should be in a test.

  assert(INT_1 == 1);

Gotcha.

What? You are going to use a global state for this? No, no, no! You ought to put that in a class ...

    class MyBetterrrrInteger(MyCustomNumberClass) implements ICalculatable {
      public static MyBetterrrrInteger(OtherIntegerClass num) {
        ...
        // oh did I forget to add generics to the mix? damn.
      }
    
      ...
    }

my issue is with it being named INT_1. If it were a constant with some meaning, I'd be accepting of it.

As is, the only way I'd approve of it is if it was required to have the value be addressable. I'm not sure how often of a concern that is in java, but in Go for example, from ~1.3 to somewhat recently sticking an integer in a interface would cause a small allocation to hold the integer. By having it stored as a variable (you can't take the address of a constant in go) one could elide the allocation by storing the address of the variable in the interface instead of it's value. Of course now go will automatically do that for small values (N < 256).

That's a pretty niche use, but it does exist. I'll assume it's not novel, and there are other, perhaps similar use cases for having a symbol instead of using the literal.

wrt https: Yeah, it should be in muscle memory, but humans make mistakes, fat fingering is a thing. Using a symbol can give you a compilation time check. Of course, you may typo the symbol and have the exact same problem. The ability to compare by address actually applies more to strings though, since you can check the address & length for equality rather than having to do a full comparison of the string. This may or may not be an issue in any given language/implementation based on a variety of reasons (string interning, multiple definitions of a literal due to runtime/dynamic loading).

I don't know if people should but people definitely do. When I review code, if a constant is inlined in several places (e.g. "https" is used instead of `PROTOCOL = "https"`), I have to check at every place that there's no typo. With a constant I just have to check once.

A friend asked me to do some web scraping for her. Since I didn’t have much time, I figured out the difficult part — some home grown encryption/obfuscation scheme used by the website in question, and handed ~30 lines of Python to another programmer friend of hers, a Fortune 500 Java programmer, to finish the remaining boring work.

A day later the Java guy got back to me with a full blown Java project three levels deep which was just a translation of my ~30 lines of Python, and it “didn’t work”. I had to read what was now hundreds of lines of Java to find 3(!) bugs in it.

That day I realized FizzBuzzEnterpriseEdtion is much closer to reality than I thought.

I wanted to some simple web scraping and wrote around 100000 lines for an HTML parser and XPath interpreter

I feel like that's code scanning tools to blame. A lot of them complain about "magical constants" even when they're cleaner than a dedicated constant

Something like `SECURE_HEADER = "https://"` and `PLAINTEXT_HEADER = "http://"` can spare real headaches down the road.

How?

The s that’s so easy to miss can make a big difference in some cases.

It just goes to prove how realistic FizzBuzz Enterprise Edition is that I can't tell when people are joking about stuff like this or when they're deadly serious.

In fact, I came across a line of code that was basically `two = 2;` in my own company's codebase just a few days ago.

There was the "hello world" from project GNU:

https://www.gnu.org/software/hello/

For a while I did not clue in to the fact that they were serious, I thought they were making fun of their own build tools...

Lack of constraints.. I'm sure having no memory, no cycles or not even computer access time made people aim at diamonds, not tar pits.

One thing I'd add over the 'screwed industry', at least in the java,model era is that the more they added, the more "tools" they needed and it was seen as a quality. Basically quadratic complexity at the cultural level..

ps: as usual, https://duckduckgo.com/?q=stop+writing+classes+pycon&t=ffab&...

Is it just lack of constraints though? Minimalism also guarantees improved maintainability and fewer bugs in the code. The less you write, the fewer mistakes you make, it's that simple.

No, not really. Minimalism where I had seen it lead to spaghetti like hard to maintain and decipher the code. It was impossible to think about larger units, you had to juggle details of everything in head at the same time.

.. that sounds like the opposite of minimalism.

Exactly the opposite in my experience. The worst maintainable code is usually the minimal ”prototype” or ”MVP” solution. Couple it with time pressured continuous development and you get spaghetti.

Maintainable code has sane abstractions, it wraps external dependencies, and it has minimal interfaces between them and other code. Minimal here doesn’t mean quantitatively minimal but qualitatively minimal.

Spaghetti is not minimalism, it's quite the opposite. You should minimize dependencies, minimize every function, avoid repetitions, etc. What you mean by MVP that evolves into spaghetti is called "incompetence".

It's not the whole story, but budgets tend to get burned, regardless of whether we're talking about money, time, CPU cycles, RAM, disk storage and so on.

> I asked them to create a library for solving quadratic equations.

To me, this reads like a requirement, can you really blame them for respecting what you asked for?

Sorry, I wasn't clear: they all built classes with more than one entry point.

I’m confused, since you mentioned a two-line-solution. Was it a library then?

You've just described quite a few software problems. They don't exist because things were too simple, they exist because something that was essentially simple got made complex. One of my better tools to deal with projects that have run into trouble is to mercilessly cut stuff away.

One such case I was permitted to write about (most of my work is under NDA), I can't believe it's already been 8 years since then:

https://jacquesmattheij.com/saving-a-project-and-a-company/

> You realize that it was so trivial that there was no need for a library in the first place.

I struggle with that all the time. Libraries always tend to accumulate such trivia. My litmus test for it is if the documentation has more lines than the code.

I hate libraries that are a mile wide and an inch deep.

> My litmus test for it is if the documentation has more lines than the code.

Not sure I am understanding this correctly. Would undocumented libraries be the best or the worst according to this metric?

Documentation substantially longer than the implementation can mean the abstraction/interface is more complex than simply reimplementing for a specific use case would have been.

Sometimes you want a library anyway in these circumstances though, since the expertise required for the short implementation might be significant.

> how someone can overengineer a solution

If his solution doesn't work with arbitrary number-like objects (matrices at the very least), doesn't support voice input, can't send results via email and can't seamlessy resume the calculations after a hardware failure, it's far from overengineered.

Matrices don’t form a field so I would say they are not really “number-like” in the full sense.

> Oh, I found bugs in his code. But that was considered normal. People make mistakes, right?

Should have used TDD/BDD, developed some Gherkin test cases, and used those to develop some JUnit automated tests before starting on the implementation. Oh, and each class -- for the solver, coefficients, variables, etc. -- needs to leverage dependency injection so they can be properly mocked in the tests...

I'm reminded of a story about Kent Beck or somebody, one of the big TDD gurus, who wanted to get a microcontroller to draw something on the screen or something. So he first wrote the program in Java, being sure to employ proper TDD principles, and then hand-translated the Java code to microcontroller assembly or something. But this was feted as a win for TDD and evidence that TDD can be used for anything and therefore should be used for everything. The details of the story are vague, and I can't source it right now, but I know it exists. Some Hackernews is bound to dig up a link, they usually do when I make an obscure reference.

I can't help but be more impressed by a guy who quite clearly genuinly likes both the programming and math, had fun with assignment.

I don't know how your two liner worked nor why it was deemed improper. I don't know whether it solved all special cases. But it in fact failed your political goal.

Unless I’ve missed a radical change in recent Java versions, Java doesn’t have free functions per se. So asking Java programmers will give biased answers.

Afaik yes, java doesn't. The closest will be static class and functions.

you can't have a static outer class in java; static classes must be defined inside of a non-static class.

AFAIK, the closest you can get to free functions is a non-static class that only has static functions. infuriatingly, many coverage tools will count the "constructor" of this class as uncovered code. stuff like this makes me really miss C++.

What so you mean by that? By static class people typically mean that every method has static in it, so you never have reason to create an instance.

Static inside inner class is something else entirely and has nothing to do with topic of this thread.

They may be trying to say that Java doesn’t have static classes that match C# static classes. In C# if a class is marked static it’s enforced as not being able to be instantiated and all of its methods (and fields) must be static.

“Simplicity is the ultimate sophistication.” – Leonardo da Vinci.

How does one solve a quadratic in just two lines? Did you omit degenerate case checks and/or number of roots?

No. Depending on the language you can find a way of returning 0 to 2 results. Could be a dynamic array, could be a tuple that allows NaN's of some sort.

What algorithm did you use? The standard formula is pretty inaccurate, whereas following most of https://people.eecs.berkeley.edu/~wkahan/Math128/Cubic.pdf, I was able to get down to near machine precision. I've seen enough cases where someone blindly copied in a formula (or numerical algorithm) from a textbook, without considering how the numerics behave, and getting bad results, to trust unsourced numerical code.

"Succinctness is power" is illustrated nicely in the array/matrix languages. Code working on time series - switching away from a matrix language seems to increase code size by a factor of x5 - x7 times. It is mentally taxing. What was a word before, is now a sentence.

Hard disagree, especially on the 90% part — essential complexity can’t be reduced. Chances are you just didn’t understand the problem domain, or you only needed a solution for a small subset of the problem which is much easier to solve.

But the 80-20 principle still holds true for many things — the rare edge cases may indeed bring a whole lot of complexity with themselves. They can easily be a difference between an O(n) algorithm and an NP one.

Minimalism is okay (in that we should strive to decrease the accidental complexity), but I found that some people overdo it to such a naive and frankly, dumb levels that it is actively harmful.