Imaginary problems are the root of bad software

If anything it&#x27;s the incentive system in software industry, which is at fault.<p>1. No designer is given promotion for sticking to conventional designs. It&#x27;s their creative &amp; clever designs that get them attention and career incentives.<p>2. No engineer is paid extra for keeping the codebase without growing too much. It&#x27;s re-writes and the effort he puts in to churn out more solutions (than there are problems) that offers him a chance to climb the ladder.<p>3. No product manager can put &quot;Made the product more stable and usable&quot; in their resume. It&#x27;s all the new extra features that they thought out, which will earn them reputation.<p>4. No manager is rewarded for how lean a team they manage and how they get things done with a tiny &amp; flat team. Managers pride themselves with how many people work under them and how tall in the hierarchy they are.<p>Our industry thrives on producing more solutions than needed. Efforts are rewarded based on conventional measurements, without thinking through- in what directions were the efforts pointed at.<p>Unless the incentives of everyone involved are aligned with what&#x27;s actually needed, we&#x27;ll continue solving imaginary problems, I guess.

The author hits the nail on the head with his claim that imaginary problems are <i>more fun</i> than real ones.<p>As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, &quot;Yeah, but when we have 1M users...&quot;<p>It&#x27;s great fun to think your product will get to 1M users. It&#x27;s also very unlikely. It&#x27;s not nearly as fun to finish and ship and market and monetize the half-broken thing the team is working on now. Yet that&#x27;s the only way out and the only way anyone gets to 1M users to begin with.

I agree with this to some extent. but there’s a flip side too.<p>This mentality is often taken way too far. I had an old boss who wouldn’t allow me to write unit tests citing this thought process.<p>Even at places with decent engineering practices, I’ve seen so many examples of software where you’re limited to a one to many relationship for something that could and easily should have been implemented as many to many, rendering the product useless to many because a product person couldn’t stand to think a couple months ahead.<p>Some people seem to take this idea too far and basically assume that if a problem is interesting or takes away a tedious task, it must be overengineering, premature optimization, or an imaginary problem.<p>Perhaps a better way to phrase the issue would be “artificial constraints”, which would encompass the flip side too.

I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. But obviously lots of software doesn’t get developed in this sort of arms-length way. I would say that imaginary problems (as the author defines them) cause failed projects by consultants&#x2F;contractors.<p>I find the rest of the article to be bizarre. The discussion around retail banking software seems unacceptably incurious and a very likely incorrect diagnosis of the cause of the problems (it basically stoops to an ‘I could do that in a weekend’ level of criticism[1]). It then transitions to a screed about Goldman Sachs which is, as far as I can tell irrelevant (Goldman do very little retail banking; their software development will be quite different to that done for retail banking), and then some description of how the author thinks (all?) large companies are (mis)run. I don’t know if Goldman was meant to be a prototype for this model of company management but it seems like a particularly strange example (in particular, they still will have some remnants from the culture of being a partnership, so they’ll be run somewhat differently from other big investment banks).<p>I found the second half did not ring true. I’m sure software projects fail at big companies (including retail banks, Goldman Sachs, other investment banks, tech companies, and so on) but I don’t find the reasons given in the article convincing to the extent that I think that section could have been written by someone who had only ever worked at very small companies. But maybe it’s just me and most companies are so obviously terribly wrong in these ways that no one even bothers to write about them and so I only see subtle ways they go wrong like projects dying off due to management acting in bad-faith ways or rewarding people for things that aren’t actually so good for the company or whatever.<p>If you’re interested in better discourse around certain kinds of bureaucracy, look into <i>moral mazes</i>.<p>[1] generally ‘I could do that in a weekend’ is code for ‘I could do some minimum thing that doesn’t actually solve whatever the important problems are in a weekend’

This resonates and one way to describe it is an incentive problem. Someone whose incentives are <i>tightly</i> aligned with the business is going to solve the actual problem and simply and effectively as possible. Someone who is incentivized to build career capital and experience other than via impact (e.g. so they can get uplevelled, pass an external interview loop, etc) is much more likely to focus on unimportant hard problems and&#x2F;or over engineer.

Great advice, spot on<p>At work we have this terrible “Enterprise Architecture” team comprising of highly paid people who haven’t written a single line of code and who don’t know the intricacies of our business but keep proposing complicated “Event Driven Architectures” and “Micro this and Micro that” and just reciting the latest buzz words just to keep appearing cool.<p>It’s insane how much total cost they add to the organization, both directly and indirectly.

I dont want to get paid and have fun.<p>I want to get paid to solve real fucking problems which has a factual validated need from real people.<p>Most people are terrible professionals. Writes code to have fun and expects to be paid too. And even blogs about it too.<p>I want to be in the trenches. Hard work. Real work. Not some glamorous bullshit that lasts nowhere. Quality long lived treasure is what I strive for.<p>And I dont want to progress by applying popculture technologies because some punks subjective opinion wants to have fun. One has to be a prick and tell these people off because they shovel shit and pad their own backs when the re-shovels it with a new fad.<p>I want to progress by making slow surgery like precision work. I want to make sure that what I do sticks and is sound quality, no code is written for fun. Code is a fucking liability.<p>Between the scams and the hustle, the number runners and the pick pockets, real people with real quality minds do real good work. Those are the only programmers worth being around and hire. Everything else is just a waste of time and mental capacity.<p>So many morons in this business. It&#x27;s really too much.

A drop of anecdata: Once had a several-days argument about deploying a fix involving an SQL query analysing information from our deployed devices because the other developers were convinced it wouldn&#x27;t work efficiently for 1000+ devices. Client was threatening to withdraw their money and support -- which would have killed the company I was working for -- if we didn&#x27;t make things work RIGHT DAMN NOW.<p>Reader, we had 25 devices.

I absolutely agree with the premise. People just love building things even when they&#x27;re not needed. After a while, your ego gets attached to whatever it is you&#x27;ve built and you can&#x27;t let it go.<p>I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard framework that solved the problem already and did it in much simpler and more elegant way. (To be fair to him, this standard functionality was only recently introduced.)<p>During his presentation, I asked why the standard solution wouldn&#x27;t work for him. It turns out he wasn&#x27;t familiar with it. Fair enough, so later I messaged him and showed him the standard way to do it and how much simpler it was. He couldn&#x27;t be swayed.<p>He just couldn&#x27;t accept that his complicated solution wasn&#x27;t necessary. He constructed scenarios where his idea was needed, even though I saw solutions to those scenarios using the standard framework.<p>Interestingly enough, one of the scenarios where his custom thing was needed was in some tests he had written where he did some complicated things to set things up. I looked at the tests and even there saw those complicated things weren&#x27;t necessary! There were ways to simplify what he was doing so that the tests were better written <i>and</i> didn&#x27;t need his custom tool.<p>Anyway, he wouldn&#x27;t be convinced. And because he couldn&#x27;t be convinced, we got stuck with his solution and saw people continue to work on it, add more functionality to it, fix bugs, etc. All of that work was just a waste of time when we could&#x27;ve relied on a standard solution, which was way more mature and way simpler.<p>All of this drove me crazy, but I realized that sometimes people are just unable to see simple solutions to problems. Worse, having one complex solution begets more complex solutions elsewhere.

How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what&#x27;s the solution?<p>Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I&#x27;ll switch company and I&#x27;ll need to find a new job. And, like it or not, but everyone these days wants a lot of experience from their workers. I&#x27;d love to write C89 in the dark corner for the rest of my days for reasonable compensation, but I don&#x27;t see those jobs, what I see is billion keywords k8s spring boot react query metrics jaeger aws yada-yada.

My venom for design patterns has risen over the years, and I think the reason is that Patterns always represent concrete architecture changes long before the last responsible moment.<p>In my code I tend to leave negative space. A spot where a feature could logically fit, without having to really design that feature before we need it. And as my comfort with compound refactoring has improved, some code smells have fallen off of my veto list. If we need to do X then this solution will stand in our way, but we can alter it here and here if that becomes a problem. It works well for a team of one, but it can be difficult to express in a code review, when someone is adding the fourth bad thing to the same block of code and now I’m pushing back for odd sounding reasons because my spidey sense is tingling about bridges too far.

this is definitely one of the advice i give to senior dev i work with: if you&#x27;re proud of how smart your solution is, there&#x27;s a high chance you overengineered and made a mess of a simple problem.<p>i now take great pride when my code looks boringly obvious.

Author gets it half right. Too many developers trying to have fun by doing new things. Affordable initial software development tends to come from places that have boring templated solutions using 1-2 tools.<p>But the main argument is off - What some classify as imaginary problems is actually building in the wrong types of affordances. The only way to know the difference is by knowing your tools and the problem domain.<p>The root of bad software is leaders lacking practiced learning.

---<p>They’ve put their heart and soul into creating this app, and it has some amazing features:<p><pre><code> A state of the art recommendation system An algorithm generating the transcript of all your streams, in real time Your front page loads in sub 200ms times all over the world A streaming protocol and client build almost from scratch, in case you don’t want to rely on Facebook live A service that allows you to easily integrate over 20 ad exchanges </code></pre> ---<p>What a dumb article.<p>This is just made up. If you hired consultants and they pulled this lawyers would be involved.<p>I stopped reading here. Why continue reading something based on a fake premise.

A long article that can be succinctly expressed by the many variations of this cartoon: <a href="https:&#x2F;&#x2F;softwarehamilton.com&#x2F;wp-content&#x2F;uploads&#x2F;2013&#x2F;02&#x2F;swing-1024x997.gif" rel="nofollow noreferrer">https:&#x2F;&#x2F;softwarehamilton.com&#x2F;wp-content&#x2F;uploads&#x2F;2013&#x2F;02&#x2F;swin...</a>

&gt; They might realize Debra has been sitting in that corner, staring at uptime graphs of the internal server farm for 10 years, despite the fact that the company moved to AWS five years ago.<p>Ouch. The tone of the article is a little harsh, and I’m not sure if snippets like the above are intentionally hyperbolic, but there is a fair amount of truth in it.<p>Most of my career has involved convincing peers to do less, and solve simpler problems with simpler solutions.

This had good points up until the point where it conflated banking software with ‘moving a few numbers around’.<p>There are <i>vast</i> differences between the pathologies that affect small scale contract web app development as detailed at the start of the article, and those that affect global enterprise development such as is required to build large scale online banking systems. The biggest difference being that many of the things which are ‘imaginary problems’ for the small time web app are very much ‘real problems’ for a publicly traded company with responsibilities to several government regulatory agencies.<p>And sure, these institutions are <i>just</i> as prone to conjuring imaginary requirements, but it requires considerably more sophistication to tell the difference between ‘something someone in the German compliance office dreamed up to make themselves seem important’ and ‘something that if we get it wrong will result in billion euro fines’ when you’re building a banking system rather than a podcast website.

Well said. It&#x27;s a relative of the premature optimization problem. I often think of them as unearned problems.

Isn&#x27;t this why companies have employees with different levels of experience?<p>Need a bog standard app to stream audio files? Give it to the person you hired right out of college, or maybe even the summer intern. She&#x27;s never built something like this before, so to her it will be a challenging novel problem. A (somewhat) more experienced developer may need to provide initial guidance and review code, but that&#x27;s a comparatively minor time investment, and besides, the act of mentoring someone else should keep it interesting.

I spend a lot of time saying “I told you so” to people who were sure my problems were imaginary. When you don’t stay somewhere long or you have a short time horizon it’s hard to connect cause and effect. Also pretending uncomfortable things don’t exist is a very popular character trait.<p>It’s not impossible that some of the problems I see others manufacture have a genesis in past traumas they are trying to avoid (some coping mechanisms are healthier than others).

Premature optimization is the root of all evil.<p>Simple &gt; Complex.<p>It&#x27;s amazing how many otherwise brilliant people dive headlong into project without considering these basic principals or even intentionally brush them aside.

Rollbacks of an integrated financial system, live and mid-collapse, built with a shockingly complex set of integrations and features on top of a series of underprovisioned distributed databases and queues, probably aren&#x27;t as simple as the author believes.<p>Yes, they should have planned to be able to roll back, but it wouldn&#x27;t have been <i>simple</i>. It would have been very difficult, and if they were fastidious enough to plan for a rollback they presumably would have done the development and migration in stages and performed parallel testing on the old and new systems, which would have removed the need for the rollback in the first place.

The hard part here is telling the difference between a pure phantasm of an imaginary problem and innovation. Things that have never been done (or never really been done well) might look as far off as hypotheticals.<p>I do think that “imaginary problem” is the answer most of the time though. Most things that look like unnecessary complexity or hobby horses really are.

Sort of related, but this is one reason I moved into “Frontend“ about 10 years ago. I started seeing over and over that when our (SaaS) projects didn’t start from what the customer sees, teams usually got distracted with imaginary or hypothetical design issues. It was a lot more effective to iterate from the visible features, and then let that drive much of the backend design, APIs, development timeline, etc.<p>This meant I needed to deal with more JavaScript than I originally intended with my career, and eyerolls from backend architect types, but projects go much smoother than in my past, that&#x27;s for sure.

&gt; It should be noted that this issue isn’t unique to developers. Management, sales, HR, support, legal, and even accounting departments have their own unique ways of creating imaginary problems. They try to involve themselves too much in a decision, when their presence at a meeting is just a formality or wasn’t requested at all. They overemphasize a minute problem that is related to their role, or hire teams much larger than necessary to illustrate their importance.<p>I run into this more often than problems I imagine. A whole series of what ifs and folks imagining things. The worst part is the fixes to their imaginary problem are usually not well thought out and drive things towards worse choices.<p>I’m a big believer in getting version 1 out the door as problems people imagine often… are never relayed by the actual customer.<p>I often work with some routing software (let’s say routing packages). There is a simple mode that works great. Anyone can use it.<p>The issue is people want to establish say 20 rules about how &#x2F; when &#x2F; what is routed. Business folks insist that it be “easy” for “anyone to use” just like the existing easy mode.<p>This is doomed from the start. We can make it easier for sure, but if you have 20 rules with different weighted priorities:<p>1. It is complex for most people to think of. It will look complex because it is complex.<p>2. That’s ok because the guy with 20 rules probably has thought about them and understand they have 20 rules.<p>Then we give them UI to visualize it all and customer is happy.<p>But the business folks are upset because the visualization is complex… and there we are again.<p>For the record I usually get through this slog and everyone is happy in the end, but it is a slog due to imaginary problems.

Even tho I&#x27;ll get flak for it, I&#x27;ll call bs on the article.<p>It&#x27;s the same as the phrase &quot;(premature) optimization is the root of all evil&quot;. Does it mean you should never optimize? No. Does it mean you should always optimize as a last step? Also no.<p>Here&#x27;s the full quote: &quot;Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.&quot;<p>It&#x27;s way more nuanced and basically says: &quot;Stop wasting time on optimizations with little gain, but still do them where they are useful&#x2F;necessary.&quot;<p>Right now I&#x27;m working on an embedded device running a small Linux. Our resource usage is well within the bounds, so thinking about better architectures or optimizations is an imaginary problem. Right? No. Not at all. Making our software smaller and&#x2F;or faster doesn&#x27;t only mean we can put on more software, it also means we could produce cheaper because we need less resources.<p>Thinking about and experimenting with different architectures or newer technologies also seems like imaginary problem solving at first, but there is a good possibility that you improve your system as well. A better architecture could make your software more maintainable or give you the flexibility to implement new features in a way, that was really cumbersome with the old code.<p>So while I agree with the sentiment that you should not implement things you don&#x27;t need, I also think that there should be room for people to experiment and try out different things. Because sometimes, the people working with the code the longest are blind to it&#x27;s many shortcomings. Because it&#x27;s normal for them to just work around them. But getting rid of those shortcomings can save you hundreds of man hours of work in the long run.<p>To cut a long story short: Do experiment. Do think about problems you might have in the future. Do the mental exercise and think about how to improve your current code and architecture. <i>But don&#x27;t blindly implement it</i><p>Always evaluate what your trying to do. Check if it improves the things it&#x27;s supposed to improve and also check if it doesn&#x27;t make matters worse elsewhere. Get to know the tradeoffs and make informed decisions if changing something that works to something that&#x27;s better is worth it to you.

This is such a great article. Amazon tackles this problem by emphasizing &quot;working backwards&quot;, but it ultimately depends on the people who enforces such cultural value. I remember in one of the Uber all-hands meetings, an engineer asked the CTO whether Uber engineers should always make sure their systems can handle at least a million requests per second. To Thuan&#x27;s credit, he unequivocally said no.

The species of this I most commonly encounter, and IMO the most illuminating of the issue, is Solution in Search of a Problem. People love having a solution to a problem so much, they will hallucinate the existence of the problem the solution is for. Especially when social approval has replaced any actual mission of the org.<p>In other words, when you have a hammer, everything looks like a nail.

OMG, never has truth been so funny and yet so tragic.<p>This article, its art and its font choice, shall be preserved forever in the archive of Historical Documents.<p>Our eternal response to unnecessary complexity? &quot;Never give up! Never surrender!&quot;<p>--<p>ADDENDUM:<p>The article makes a good case for formally adding &quot;manufactured complexity&quot; and &quot;miscommunication complexity&quot; to &quot;accidental complexity&quot; and &quot;necessary complexity&quot;.<p>They are quite common distinct causes.

Ah yes. This explains very well why, when I ask our corporate IT for a static website with essentially text + some PDF downloads, I keep ending up in a “web platform” project based on a fiendishly complex CMS that is made for running large-scale e-commerce sites — of course delivered after ages and requiring multiple rounds with the CFO to justify the increased budget.<p>Been through that at several companies now.

On one project I did it was essential to be able to record how much a tool was used so that we could charge for it. The tool ran locally on the customers&#x27; machine and reported to our service. The overall mechanism that sent and received this information had to be reliable or we&#x27;d lose money but even worse would be to in some way overcharge customers. Lots of aspects of the design were complicated by this concern.<p>Then we ended up deciding not to make money out of it that way. So we burned enormous effort and created a horrible design for no reason.<p>So IMO the problem is usually with the way requirements are not usually well understood even by the people asking for them. Later on it becomes clearer what is needed but you&#x27;re stuck with false assumptions baked into your design in a way that you never have bandwidth to remove because you need so much bandwidth just to do normal work....because of those assumptions.

It seems like the fundamental problem for the scenario presented in the article was an inability of the customer to communicate their strategy and a completely hands off approach during implementation when they should have had at the very least biweekly checkins with developers with pre-negotiated milestones.

It might be more general than that: imaginary problems are at the root of bad___<p>Where ___ could be something produced like software (or furniture, etc.), or theorised such as scientific theorems (as even though thought experiments are useful, if we don’t go beyond them, we are often lead to bad science), etc.

It’s impossible for a large organization to operate as efficiently as a tiny one but I also don’t really believe the article’s implied claim that “a couple smart guys” could solve essentially any given problem to clients’ satisfaction within a reasonable timeframe.

I frequently refer to this as “It would be cool if” driven development.<p>Crucial to fight against this kind of stuff.

If you only paid $15,000 for all of that technology after only two months and you&#x27;re salty about not having automatons carrying out your commands, you probably should just stick to your podcast show and thank everyone for delivering something, even if it&#x27;s a few shades different than what you asked for.<p>These aren&#x27;t imaginary problems but interesting solutions. I&#x27;d bet that card punching programmers working on the first computers were the first to build interesting solutions along with addressing requirements. Look at how far managers have evolved since then.

&gt; Most complicated or broken software is not designed to be overly complex or dysfunctional.<p>I beg to differ. This might have once been true, but no longer. Now developers demand a massive arsenal of dependencies before they are even willing to start on any project.<p>You say you need a web page and a few events? No problem. I will just sprinkle in some React, Redux, Grunt, GraphQL, PM2, and a plethora of plugins for each with a cascading list of dependencies for all those plugins. We absolutely cannot do less, because the risk of writing original code is too costly and we value retaining employment (blaming someone nameless outside the company).

The author is right, but doesn&#x27;t seem to mention that this could be solved, at least in theory, with better project management. Devs focusing on the wrong thing? Project manager should be on it. Scope creep? Project manager should be on it. Client asking for irrelevant features? Project manager should be on it.<p>Replace those devs with ones who are focused on the right things? Great, but you still have the other problems to deal with (scope creep, uninformed clients), not to mention a host of other things that can derail a project, such as poor communication.<p>tl;dr Most projects are poorly managed. Poorly managed projects tend to fail.

If the company structure is too complex or too big and your actual impact is either hard to measure or is held back by the system or by colleagues, you have to find a way to stay sane and find a tangential meaning in work. Funnily enough, this doesn&#x27;t mean it is wasteful. It could turn out that it makes you put more energy in honing your skills, or perhaps you find a way to contribute to open source within your job. Neither are bad things. So I don&#x27;t completely share the pessimistic outlook of the article.

Big tech internal incentives really exacerbates this. The entire performance system incentivizes engineers to create imaginary problems and solve them. Honestly, I think a good chunk of engineering activity are along these lines. Literally just imaginary problems being created which compound into more imaginary problems, all which are used by engineers to justify their existence.

The article rests on the idea that the management knows what needs to get built, but my experience so far was that they are usually even worse at that.

I like the first part of the article, but then he wents off to some weird rant about banking software that gets old quickly

I do agree with the general premise but there are a lot of passages that kinda trivialise a lot of complicated phenomena, e.g.:<p>&gt; Much like victims of childhood hardship or abuse can find escape in fantasy books, victims of enterprise programming or freelance web development can find their escape in solving imaginary problems.

I know it’s just an arbitrary number picked but this bit jumped out at me:<p>“You’ve just wasted $15,000 on two months work with a team of contractors”<p>The project may also have been doomed because $15k is not very much for something like they described.<p>But again, fully aware that they probably picked a random number. I’d have just added another zero to make it more realistic.

Summing it up:<p>* Communicate effectively - avoid middle layers<p>* avoid over imagination &#x2F; premature optimization<p>* Incentivise for organisational efficiency

This is why I truly love support-driven development.<p>While it’s possible to prioritize problems that don’t affect most people (squeaky wheels) it’s a hell of a lot more effective than most of the methods I know to have a very low barrier to contacting you for users, and fixing the things that come up.

Engineers are terrible prophets.<p>We should focus on the problems of &quot;now&quot;. The future will catch up.

I really like this quantification of crash rate and being so up front about it and what’s acceptable. Spending such a long part of my career being in the critical software space it’s kind of refreshing to imagine a more lax world out there.

This is a good addentum to the Bullshit Jobs thing that was posted a few days ago.

I gave up on this article when I found out that the first hypothetical scenario has no relation to reality.<p>Implementing something else “because if they implemented the real spec they would get bored” is too much psychology.

So it&#x27;s resume driven development that&#x27;s causing issues?

My favorite example of this is the grocery store checkout kiosks that make you weigh each item. So much wasted effort both to produce and use those machines.

In the imaginary case of the merch selling android app i dont think it is justified to solely blame the developers for the bad product. The root cause for a bad outcome lies in the simple fact that nobody wanted to tell the client that there was already a solution for 20 bucks and absolutely no need for something custom built. NOBODY except the business owner gains anything in this and the client deserves the ripoff too. It comes as no surprise that developers look for interesting challenges without appearing too distracted by the stupid and boring bs work they are stuck with.

Imagine someone writing small webapps for small companies and extrapolating to assume this is applicable for extremely large scale software design…

Developers have a lot in common with Rube Goldberg

&quot;Rule Eight: Don’t try to create and analyze at the same time. They are two different processes.&quot;<p>— Today You Need a Rule Book, 1973.

We have beef with AI hallucinating - get 5 people to work on a problem and measure how much stuff they will make up from thin air.

&gt; secure online banking is actually quite an easy problem to solve . . . The storage and transfer of numbers is not a particularly hard problem.<p>I don&#x27;t know anything about banking software, but I have a hunch the author underestimates the complexity (as is typical for HN). The Efficient Markets Hypothesis would suggest that if it were so simple to make banking software, then someone would do it.

The main imaginary problems I commonly see are wheel reinventions.<p>For the most part, the software I see works well for what it does, and either has far too few features, or else all the extra stuff they added is stuff that people actually use.<p>On social media things are different, that&#x27;s been bad and unsalvageable from the moment endless scrolling made it into something people spend significant time on.

What does ICO stand for? Or ICO-ed, as it is used in the article

Ted Kaczynski’s “surrogate activities” term is very relevant here.

“Imaginary problems are the roots of negative developments”

&quot;Premature optimization is the root of all evil&quot;.

Imaginary problems are the root of all problems<p>Maybe a Buddhist could say

What&#x27;s a &quot;real&quot; problem, though?

Imaginary problems aka gold plating and yagni.

So very funny! In a highly cynical way.

that implies:<p>bad software = -1 problems

This sentiment get repeated a bunch but I doubt it&#x27;s really true.<p>Bad languages and tooling is the root of bad software.