Overengineering can kill a product

I don&#x27;t think you can diagnose over-engineering after the fact. Unless you were in the room, or have access to written specs from a meticulously documented team, you don&#x27;t understand the conditions under which the code was written.<p>Maybe the company was betting at the time on an integrations marketplace, or a lot of partnerships, so a robust integration platform was built. Then the company moved on to another bet after only writing one or two integrations on the new platform. Nobody over-engineered here. Everything was built to spec. But three years down the line the new dev is going to get assigned a bug in one of the integrations and lament how the code was over-engineered. Hindsight is 20&#x2F;20.<p>Lots of stories from the trenches including many in this thread make this mistake. The same goes for &#x27;tech debt&#x27;. If you weren&#x27;t there, you don&#x27;t know.

One thing that bugs me is the notion that &quot;Software rewrites are something you should never do&quot;, which is a mantra so often repeated that it has acquired the status of self-evident truth, despite the only evidence being (usually) presented is an example of a web browser from 20 years ago! (Which incidentally spawned Mozilla, so not exactly a complete loss; especially from the POV of society rather than shareholders, but I digress).<p>Having rewritten a bunch of systems (sometimes several times) I can attest that it will not always lead to the death of the company. The trick is of course having modular enough systems that they can be rewritten from scratch in a reasonable amount of time.<p>It can also be a great way to increase the simplicity of the system as typically the old version was designed with a very imperfect understanding of the problem and no operational experience servicing it; further learning were usually crudely patched on top and you often end up in a conceptual hodge-podge where words mean subtly different things depending on the context and translation layers need to be inserted between the contexts etc.<p>Often a (good) rewrite starts by clarifying the conceptual model. I like the saying &quot;clear writing reflects clear thinking&quot;, and in programming there is a lemma &quot;clear thinking produces clear code&quot;.

Complexity kills your product - Overengineering is just one instance of complexity - Technical Debt like having state and data all over the place is another one - I quit my last job and I happily blame this article for convincing me to quit: <a href="https:&#x2F;&#x2F;itnext.io&#x2F;the-origin-of-complexity-8ecb39130fc" rel="nofollow">https:&#x2F;&#x2F;itnext.io&#x2F;the-origin-of-complexity-8ecb39130fc</a> - coordination causes complexity and this killed me - we had everything not once but twice or more in different places - just one example - it&#x27;s much more complex but me and my colleagues were grinded between an old codebase that nobody understood anymore and kubernetes, ci, etc.pp on the other side because management sold this without understanding that you need a process and time for digesting and applying the concepts in the team.

Six months ago I left a company that was working on an overengineered product. Even worse than it being overengineered was that it was also under documented. Working on anything was a pain, because the CTO wanted everything to follow his well thought out, and frankly very cleverly engineered design patterns, but he couldn&#x27;t clearly communicate what those patterns were. And the entire company amounted to transforming and cleaning data sets using in-house tools, which could easily be done with existing tools too. Both myself and the other senior engineer on the team left at the same time. I felt bad leaving them, because they were trying to grow and had a ton of funding and deals with FANG companies but they were struggling to find engineers that the CTO thought were smart enough. I didn&#x27;t want to burn bridges, so I didn&#x27;t end up telling them that the problem wasn&#x27;t a lack of qualified engineers, it was an over-engineering CTO who struggled to communicate.

The most important thing is to find the right balance. This article goes into one direction. But to be honest, most of the time I see it shift into the other direction: in product driven orgs the drive to implement features and bring them to market quickly is more important than engineering quality. But in the end you end up with something where implementing new features takes so much time because of the complexity that built up because you started to implement a product where the specs where unknown in the beginning and only materialized later. That&#x27;s the point when you should re-engineer your system. But yeah... it&#x27;s all about balancing and finding the sweet spot.

I think there&#x27;s a very specific form of overengineering afflicting products currently, which I&#x27;d classify as &quot;endless revisiting&quot;. This is where companies build something which works well enough, but then get trapped in a cycle of endlessly tweaking that one thing. Inevitably the amount of code churn in this one area combined with the need for some semblance of backward compatibility results in something that is fragile, complex and slow.<p>Plus the annoyance as a user that whenever you use this thing, all your tools are in a slightly different place and work slightly differently to how you left them. IMO there&#x27;s a need for better balance between &quot;it works well enough, leave it alone&quot; and &quot;we haven&#x27;t fully optimised this workflow yet&quot; in product development.

The issue here isn&#x27;t so much over or under-engineering, but rather &quot;Are we building the right thing?&quot; or &quot;Are we building the thing right?&quot;<p>In a startup you don&#x27;t know if you&#x27;re building the right thing so trying to build it right is premature optimization. Since you have limited resources you really have to focus on ensuring that you&#x27;re building the right thing...if you aren&#x27;t it doesn&#x27;t matter how well designed or built it is no one is going to use it.<p>Once you&#x27;ve validated you&#x27;re building the right thing you can start focusing on building it right, but by they you probably know where the pain points are and where you need to spend the effort.<p>The trick with this though is that everyone needs to be aligned on that approach and be honest about the fact that corners may be being cut to get something working fast. Where I&#x27;ve seen this go badly is where a crappy initial version was built to get to market fast, but then no time was made available to address the defencies in the initial release.

The &quot;super simple code&quot; at both ends of the graph aren&#x27;t equivalent. The latter is more &quot;simplest code possible&quot;.<p>Overly simple, hacky, narrowly spec&#x27;d code produces the same tech debt as overengineering. Anybody who&#x27;s worked in a move-fast-break-things type startup will know how much engineering resources are wasted on rewrites&#x2F;bugfixes due to this.<p>Ultimately, as with many things in life, you need to find the right balance.

On the other hand, simplifying an already over-engineered product is almost next to impossible simply because many jobs depend on it. Maybe I&#x27;m cynical but I&#x27;m beginning to think that software complexity grows until it justifies all the head counts in the department.

I&#x27;m wondering about this now I guess it is old fashioned now to use environment variables and bare EC2 servers, managing your own APIs and websockets&#x2F;DB on same server as opposed to breaking everything out. You need to use cloud formation and &quot;oh did you know there is an AWS service for that?&quot; Then you are using 5 services instead of 2. This twelve factor app concept. Don&#x27;t know when is the right time to do this&#x2F;at what scale.

As others have said, it is unecessary complexity. Over-engineering is an ambiguous term.<p>For example, premature optimisation is frequently mentioned as over-engineering but is it premature optimisation to use a map&#x2F;dictionary instead of an array for key-based access? Nope. That is just correct. Is it over-engineering to know that if your product succeeds, you could end up with X-hundred objects which will use up all the RAM you are storing them in and therefore you might want to make them smaller&#x2F;store them off-board? Of course, you can come back and refactor later but it is so much easier for the person who writes that code to understand what can be done on day 1 rather than assuming it is cheaper to refactor later only when needed.<p>I think a better take is for people to accept that no app lasts forever. If we build that assumption into our worldview, it will help us make better decisions. I still think some engineers think there is some perfection that means the app will live forever.

I&#x27;ve written a lot of complex stuff. In fact, I&#x27;m doing it right now.<p>There needs to be a &quot;sweet spot,&quot; where we have enough complexity to achieve goals (which can be business and cultural, as well as technical), and as much simplicity as possible.<p>A lot of folks think that using dependencies makes the project &quot;simpler.&quot;<p>It does, for the final implementation team, but that complexity still lives there; along with a <i>whole bunch</i> of cruft, tech debt, potential legal issues, security issues, etc.<p>Unfortunately, you can&#x27;t do complex stuff, simply. Some level of complexity is <i>always</i> required. Managing that complexity is where we get to play adults.<p>T.A.N.S.T.A.A.F.L.

Seems too oversimplified and biased.<p>Probably missing few core points:<p>1. Without good development practices due to lack of Experience or plain old Rational Thought the only possible outcome is Operational Deficiency.<p>Every Best Practice is context-dependent, thus having Deficient Resources makes them inapplicable in certain cases. Some teams can really suck with the same tech stack when others flourishing using it.<p>2. Basic organizational anti-patterns, like Mushroom Management, and broken retrospective lead to rediculous outcomes.<p>Even plain old Micro-services and Micro-frontends can be a basis of Stovepiping and applying Mushroom Management. Usually, again, due to Lack of Competence and Sheer Hubris.<p>3. “Premature Optimization” only used in context of over-engineering by those who didn’t read the book, but use Halo-effect cognitive bias to project compensated qualities onto the term itself. There are a lot of Psychological Compensational Needs under the hood.<p>It’s like “Why Agile has nothing to do with Discipline ?” or “Why senior developers turning the project into a sandbox due to the lack of self-fulfillment ?” or “Why most of the MVP’s lack Concise and Validated Definition of Viability ?”<p>Complex doesn’t mean Hard or Expensive. Simple doesn’t mean Easy or Cheap.<p>Too often “over-engineering” is just an organizational and psychological issue and not an Engineering one.<p>Stop operating on Feelings. Six Sense of the Fifth Body Anchor Point is not a reliable Key Performance Indicator.

&quot;Stop overengineering&quot; was the excuse I heard back on a rough project when I insisted we add logging beyond just the returned HTTP status code to our service before shipping to 200M+ people. But that would take an extra week or two in the current system and that&#x27;s just too much investment for some silly over engineering.<p>Had we gotten decent logging in place early, we could have saved a terrible change that got passed our canary rings, which got us called to see the CEO and made news.<p>So, I learned early that &quot;overengineering&quot; can also be a management excuse for cutting corners that shouldn&#x27;t be cut.

The biggest consequence for me was not mentioned: that your carefully planned design very soon becomes an obstacle to something a user actually wants done, at which point you say &quot;we can&#x27;t do that&quot;. Which is one of the worst things you can do. In this sense almost all of the systems I interact with, modify etc. are over engineered.

Interestingly, dang (HN mod) once mentioned in a feature request comment that he has a mental model of a complexity budget. This very closely fits my own perception: You can only add so much complexity to a system before it starts to break down under the load. Estimating that budget, and how much new features will consume, makes a good engineer in my opinion.

Another problem is that these overly complex systems are often very fragile when something changes. In a <i>very theoretical</i> situation there could be a case where someone with an overengineered client consumes your JSON API and their client breaks when you add a field to a certain service response. Something that should have been no problem suddenly causes total breakage of your software and then you&#x27;ll have to alter that very complex piece of software. Something that could&#x27;ve been prevented if you kept things simple and robust and simple chose to ignore extra fields or headers you weren&#x27;t using anyway.

Oh boy, does this ring a bell with me. I&#x27;ve already written 5575LOC according to cloc (and threw away 7449LOC in the process) and I&#x27;m far from finished writing the code to email the data from a contact form in PHP. But it ticks all the boxes!<p>It&#x27;s all OOP<p>SOLID principles<p>99,6713% typed (according to psalm)<p>Purposely written to be unit-testable in PHPUnit strict mode (but no actual harness yet)<p>...I&#x27;ll show myself out

I suspect under-producting has killed far more products than over-engineering. The ratio of decision making power to decision making abilities is way out of balance for most Product Managers. Even at the big tech companies I feel most PMs are unimaginative MBA types that can optimize but not innovate and have no grasp of the concept of opportunity cost.<p>In terms of power structures, Product Managers decisions largely go unchecked in a lot of places. Engineering decisions face significantly more scrutiny, especially in places that work in short sprint cycles.

From a UI&#x2F;usability perspective, one of the dangers with overengineering is the &quot;wall of options&quot; issue, where all users - even the majority of them that just need something simple - still need to read and understand all these advanced options. As a product manager and UI designer you have a couple ways to deal with this. You can choose an opinionated subset of features that make sense for a given niche and target only that demographic. You can go the corporate way, keep the wall of options and just require training for users. Or you can try the balancing act - choose a sane subset of features as the default, and hide the more advanced options, so they don&#x27;t bother normal users, but still have them as possible options. There are many important choices regarding how much to hide, and where, and how to make it discoverable, and how to make it possible to gradually dig deeper, and for users to self-identify as someone that needs to dig deeper - and those details are often as much art as science. But get it right, and you&#x27;ve got one of those rare killer apps that both newbies and experienced users enjoy.

These are just fantastical musings of a product manager, who is pretty far from engineering, and thinks that their products fail because of engineers, not because they didn&#x27;t get their product right, and&#x2F;or think that every engineer who doesn&#x27;t produce a fully functional Facebook with news feed and friends, in 39 days is overengineering their product and are far removed from users!

Fwiw, my experience is that generally a lot of blame for over engineeering tends to be lumped on engineering when in reality its usually a wider business failure.<p>Every competent engineers I have met has been capable of grasping that: - They shouldn&#x27;t rely on the use of crystal balls. - Complexity should be minimised. - If it can be done today, it can be done tomorrow.<p>So if a business provides its engineers with: - A process that helps them develop an intuitive understanding of their customers&#x27; needs. - At least one other similarly capable person to work with so they know they&#x27;re not the only person going to be looking after the project off into the future. - A procurement process for off-the-shelf solutions that is less painful for them than rolling their own. - Time to test and document where projects should go if the initial version is successful. - And crucially, confidence that they&#x27;ll be given enough time to do the additional work if it becomes necessary.<p>Then the business, at least in my experience, will be in a pretty good position to prevent almost all over engineering.

I often find myself prefering languages with few abstractions even when some more complex language might be &quot;better&quot;.<p>Reason is that with &quot;bare&quot; languages like C, you can choose your own design more freely. Case in point: Serenity OS.<p>Author of that OS replicated entire libc and still refuses to use C++&#x27;s STL. He created his own abstractions that he feels confident using. That is true engineering.

The concept of overengineering is good on paper, but in practice it&#x27;s being overused and not understood precisely.<p>I see devs freaking out when you use the word abstraction now...<p>Suggest extracting business logic from a React component and you don&#x27;t know anymore if someone is gonna raise the &quot;overengineering&quot; flag.<p>If you start a new project, do you not use any library or framework at the beginning?<p>Obviously you take decisions according to how much the project&#x2F;feature is expected to scale.<p>If your estimation was too low, you might cripple your development at some point, and need a rewrite or at least some significant refactoring.<p>If it was too high, I guess you overengineered.<p>What matters is asking yourself the question, and of course as engineers we like to challenge ourselves into building the best possible solution, but we equally need to consider how likely it is that such a solution is never needed.

In the enterprise I see this all the time. Step one of the project is lets look at kubernetes or whatever is hot lately. Even for something stupid with 10k users max. What they actually need is a 30 line terraform script and a preconfigured AMI.

<p><pre><code> What is overengineering? Code or design that solves problems you don’t have. </code></pre> That&#x27;s beautifully put.

The best designs are so simple that people do not even understand that it is a design. That is one reason why it looks like senior devs write simple code.

Making overly complex products developed in an absence of engineering input is also a major issue, at my last employer this was endemic to everything product threw at us. If you have no concept of how difficult something is to build you have no reason to not require it; by the time it gets to engineering its either too late to change or results in endless CRs to fix.

I&#x27;m seeing this a lot with several of the &quot;devops&quot; or cloud architects (or whatever the preferred title is these days for the guys who manage the apps running on the servers) that we&#x27;ve hired in the last year.<p>I&#x27;ve noticed two distinct types:<p>* The &quot;AWS cert&quot; admins who have a dozen different cloud certs, but little practical experience. Every problem is to be solved using some over-priced, over-engineered conglomeration of cloud service. It doesn&#x27;t matter if it&#x27;s just an internal app to be temporarily used by a few dozen users for 6 months, they immediately begin following some &quot;best practice&quot; guide by setting up some complex multi-region, multi-subnet, read-replicated, load-balanced, auto-scaled, content-delivery-networked, containerized, Cloud-Formated, hourly-snapshotted, hot-swappable, OAuth secured and social media-login-enabled, automated environment that would be appropriate for only some retail giant&#x27;s Black Friday operations, not a single CRUD app, to be used only temporarily by 10 users in HR dept.<p>* The &quot;automation expert&quot; who takes the requirements to set up and maintain a few environments (e.g. dev, test, and production) that might need to be re-created only a few hours, 1-2x per year, and instead spends weeks crafting some monstrosity in Ansible or Cloud Formation or Terraform, complete with all sorts of required infrastructure servers that themselves bigger and more complex than the actual working environment itself. And what&#x27;s worse is that none of these frameworks like Cloud Formation are ever 100% anyway, so you can&#x27;t just &quot;push a button&quot; and create a new environment. Instead, there are a dozen holes in the different tools that need to be manually plugged when run, so it&#x27;s not like a developer or junior devops person who doesn&#x27;t know the environment inside and out or understand the undocumented quirks could use it themselves anyway, if and when the original guy leaves the company.

I found this to be the most important line in the article (author was referring to when Hiring Senior Devs, but it applies to everyone in the firm):<p>Stick with those who put the user and simplicity ahead of simply technology solutions.<p>Users are #1. It’s a constant battle between diving into the code&#x2F;technology and reaching out to users and customers.

I own an ecommerce company, and I&#x27;m using a huge (&gt;$100M funding raised) company that&#x27;s supposed to be a tech-enabled 3PL.<p>It was a terrible choice, and their idiotically overengineered solutions are a big reason why.<p>The most egregious one is that instead of weighing packages to find out their weight, they have an algorithm that estimates the weight. My packages are designed to come in at just under a pound (it&#x27;s a big cutoff for shipping prices). Needless to say, slight problems with their algorithm can and do lead them to overbill me.<p>A ton of work when they could just use a scale to do the job much, much better (and I&#x27;m sure save time overall with all the refunds of overbilling factored in).

So many things can kill your product. And I agree that having an engineering-led product can be especially prone to the dangers of over-engineering... but...<p>Not having users &#x2F; customers can kill your product.<p>Not building the right features can kill your product.<p>Not doing enough testing can kill your product.<p>Doing too much testing can kill your product.<p>Having toxic &#x2F; inexperienced &#x2F; unmotivated staff can kill your product.<p>Having a bad marketing plan can kill your product.<p>Not having enough staff can kill your product.<p>Not having enough funding can kill your product.<p>Technical debt of all kind can kill your product.<p>Bad data schemas can kill your product.<p>Under-engineering can kill your product.<p>Over-engineering can kill your product.<p>...<p>This is in no way a complete list, but from my experience the items on this list are ordered with the ones most likely to kill your product put at the top.

Just use cron job as escape hatch for the backend is always a workable solution to me.

Over engineering also have a way to burn people out when a very vocal engineer say it is imperative that this and that should be scalable and secure. It delays actionable areas before people even want to hack you or use you

Overengineers will find an edgecase or an hypothetical future scenario to justify their overengineering.<p>unless there is an org level commitment to not using &quot;what if in future&quot; type scenarios, overengineers will win everytime.

Over-engineering can inhibit or delay your work (art work) from becoming a product, but it cannot kill your product alone.<p>In some cases over-engineering may even lead you to stumble upon interesting discoveries or to innovate.

On a related note, see &quot;Don’t waste $1 million on devops infrastructure that you’ll never need&quot;:<p><a href="http:&#x2F;&#x2F;www.smashcompany.com&#x2F;technology&#x2F;high-availability-is-not-compatible-with-mvp" rel="nofollow">http:&#x2F;&#x2F;www.smashcompany.com&#x2F;technology&#x2F;high-availability-is-...</a><p>This is a true story about an entrepreneur who was suffering a bad case of perfectionism. Instead of showing his MVP to potential customers, he just kept investing in the software, chasing an almost impossible ideal of high availability

While &quot;overengineering&quot; is usually defined as making things too complex, I think it is a bit misleading, that&#x27;s because simplifying, removing or making things cheaper is also engineering. In fact there are many well paid engineers who work full time simplifying things.<p>As much as I hate the cult of Elon Musk, I have to admit that&#x27;s one aspect of engineering he really gets, and I suggest you listen to his interviews with Tim Dodd &#x2F; Everyday Astronaut, where he gets technical, trust me, it is not the usual bullshit.<p>All that to say that &quot;overengineering&quot; is bad doesn&#x27;t mean you shouldn&#x27;t have a lot of engineers working hard on a problem. In fact, a lot of &quot;ovengineering&quot; is the result of not enough engineering. They picked a (complex) solution without thinking instead of really studying the problem.

A critical job of a system designer is to see into the future and know which components need to be made custom so that the business can have the flexibility to make the changes where it needs them.<p>Over engineering is a term that is as useful as saying - product requirements list was too big - features were never communicated clearly (tree swing comic..) - right people &#x2F; people with relevant experience were not hired..<p>I make sure to always &quot;Engineer Just Enough TM&quot;

Overengineering is a non technical problem but of course most tech companies only interview devs on their technical skills.<p>I&#x27;ve found is that once a dev has an idea of how something is suppose to work it&#x27;s hard to get them to think in a different way about that thing. So when that thing doesn&#x27;t work out for some reason they just keep adding exceptions and adding exceptions until you have the horribly over-engineered solution.

&gt; overengineering has killed more products than the absence of good development practices<p>But as the author defines overengineering, it is clearly not a good development practice.<p>Further, there is no evidence provided to support the claim.<p>Maybe a truer lesson is that the authors work suffers under too much scrutiny. We&#x27;re all better off imagining a similar thesis and then imagining it is actually true.

I never understand why people criticize using interfaces for most functionality. How else do you write effective unit tests? Interfaces with dependency injection make unit tests far easier to write. Smartly designed interfaces also make code easier to read and understand. Lastly, adding new interfaces is trivially easy, so why not?

Engineering here must be in quotes, because real engineering is about simplicity and justrightness, like any craft.

Wonder if the current hiring and rewarding contributes to over engineering?<p>How would you look if you just invoked APIs to get your work done versus designed and implemented an end to end solution.<p>Many times, I have seen over engineered solutions come from promotion attached initiatives.

Interesting interview of Lex Friedman to Kevin Systrom co-founder of instagram where he talks about the beginning of the platform and overengineering.<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;3pvpNKUPbIY" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;3pvpNKUPbIY</a>

The insidious thing about over engineering is that it&#x27;s usually committed by very experienced engineers. Experienced engineers rarely under-engineer, that tends to be fixed very early in one&#x27;s career.<p>As we get more competent and read more books, we have the tendency to get enamored by new fancy abstractions. We get too clever and then we get in our own way.<p>Best real-world example: I inherited a project that was an giant &quot;microservice&quot; with 50-ish endpoints, and a Mongo database and dozens of collections. After probably 3 months of wrestling with this thing I had a realization: &quot;this whole thing can be just a simple command line tool and one collection in Mongo&quot;. That reduced the code by almost half and it became so much easier to work with. It&#x27;s frustrating that it could have just started this way.

I agree with this statement; it&#x27;s better to put some updates slowly over time but not to the point that it will transform the whole product.

Posts arguing against over-engineering are catnip for the HN crowd! In other news, kittens and puppies are adorable.

At first I thought that the article will be about putting so many features, that “in the end it will be able to send e-mail”. Because this is what is killing products - adding, and adding and redoing design as if users really were begging for it. And then comes new product that is leaner and more simple and takes over the old product and cycle starts from the beginning. I think that in capitalism it is not possible to not overengineer a product.

Engineering within the wrong paradigm can kill your product.<p>I see far more problems on a day-to-day basis with patterns and anti-patterns taken too far. For example, I never use the factory pattern, because it leads one down the Java road where everything ends up an object with mutable state. Which isn&#x27;t scalable over some metric (like a million lines of code) because a human brain can&#x27;t trace execution, even with a debugger. A far better pattern generally is to take a functional approach of accepting data, swizzling it, and returning the resulting data without mutability or side effects.<p>Another really bad pattern is when execution suspends and resumes somewhere else (goto hell). Any project which uses queuing, eventual consistency, promises, nonblocking streams, even basic notifications or things as complex as monads will encounter this nondeterminism and inability to statically analyze code. Note that pretty much all web development suffers from some aspect of this due to its async and multi-signaling nature.<p>So what I do now, which I don&#x27;t see much these days, is solve problems abstractly in a spreadsheet (pure functional programming), in the shell (the Actor model) or as a flowchart (declarative and data-driven design), and then translate that to whatever crappy language&#x2F;framework I have to use for the project. I find that today, roughly 90% of developer effort goes to discovery, refactoring and testing of ill-conceived code. Only 10% is &quot;actual work&quot; and that&#x27;s probably a stretch.<p>Which is incredibly heartbreaking for me to see, since I grew up on software like HyperCard, FileMaker and Microsoft Access which solved much of this in the 1980s and 90s in a no-code fashion. One of the very first &quot;languages&quot; I used was a visual programming environment called Visual Interactive Programming (VIP) for the Macintosh by Mainstay, which unfortunately today I can find almost nothing about, to show what an impact it had on computer science hah: <a href="https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=Visual+Interactive+Programming+VIP+by+Mainstay+Macintosh&amp;t=h_&amp;ia=web" rel="nofollow">https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=Visual+Interactive+Programming+VIP...</a><p>With mainstream languages and frameworks like Node.js and React, and their predecessors like Ruby on Rails and Angular, I just keep thinking to myself &quot;never have I seen so much code do so little&quot;. It&#x27;s all overengineered man!<p>Some better alternatives to the status quo:<p>Simple Made Easy: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LKtk3HCgTa8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=LKtk3HCgTa8</a><p>Object-Oriented Programming is Bad: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QM1iUe6IofM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QM1iUe6IofM</a>

YAGNI

Duh

If you find yourself over-engineering due to stuff you think you should be doing, things that ‘real developers’ do, understand you are vulnerable to being pimped. It’s no different than anyone else handing over their common sense and self worth in pursuit of an abstract form of validation (so abstract that you can internalize the validation cycle even in the absence of a physical superior).<p>If you find yourself defending your bad over-engineering and those that sold you the lifestyle, understand you are fully pimped and are now defending the pimp, even to your own detriment.<p>Happens to all of us from time to time, snap out of it. Don’t get pimped by ‘faangs’ or ‘notable person of interest’. Don’t listen to everything I said either, lest you want to get pimped by me.<p>Unless you can wholeheartedly make an objective argument for why you used a pattern, a tech stack, a process, in plain simple words, sans ‘that’s how the big boys do it’, sans ‘this makes me a real developer’, you are simply pimped and spewing out pimped out thoughts of your overlord pimps. Be ready to be wrong and backtrack and own the mistake and correct course, but don’t you dare hold on to it, or I’ll probe to see who is pimping you out.<p>I was never more free from my overlord developer pimps until the day I realized they evangelized impractical solutions. Never hoe’ing for anyone ever again.