   [book_front.svg] [book_back.svg]
   night mode
   ____________________ (BUTTON) Subscribe

   [1]RSS
   Add this blog to your rss feed
   [2]github logo
   Pollute your mind with some of my other missguided creations on Github
   [3]email icon
   Contact me at: george@cerebralab.com
   [4]twitter logo
   Publicly berate me on Twitter

   [5]Audio version (read by a tts bot)

Imaginary Problems Are the Root of Bad Software

   https://upload.wikimedia.org/wikipedia/commons/c/c0/De_Rebus_Bellicis%2
   C_XVth_Century_Miniature.JPG There are many factors which can be a
   catalyst for bad software: from the tools being used, to team
   communication, to the personal stake developers have in its success, to
   the testing methodology.

   I propose that there is one problem chief among them, an impetus for
   bad software from which almost all others take root: imaginary
   problems.

   Most complicated or broken software is not designed to be overly
   complex or dysfunctional. It’s just designed to do something other than
   its intended purpose.

   Let’s say you’re a podcast host who wants a custom website where you
   can sell your promotional products, make advertising money without a
   third party cutting in, and, most importantly, deliver podcasts,
   videos, and blogs to your audience.

   The requirements for your little web-app might look something like
   this:
     * Fast load time in North America, with real-time podcast streaming
       and downloads
     * Doesn’t crash or freeze in the first 15 minutes for 99.99 percent
       of users, preferably never crashes or freezes
     * Integrates well with Google Adwords and maybe some other
       third-party ad providers as well, if there’s time
     * Dynamically links to the latest products in my Zazzle shop and, if
       possible, gives recommendations to users based on the content
       they’ve consumed
     * Integrates with Facebook live player. If it’s easy to create an
       alternative solution for streaming that doesn’t require Facebook,
       even better

   You give these specs to a team of contractors, and you chat about them
   a bit. It seems that everyone is on the same page. Yet, when they
   return with the Minimum Viable Product two months later, your face
   turns red. You’ve just wasted $15,000 on a piece of garbage; you want
   your money back.

   The first time you open the app, the screen freezes. You ask how to
   select what kind of ads should be allowed to run on the site and are
   pointed to an ugly, hard-to-understand custom user interface (UI). Half
   the links to your merchandise on Zazzle are broken or missing images,
   and the Facebook livestream is laggy!

   But the development team is confused at your anger — rightfully so,
   from their point of view — because they’ve gone to hell and back for
   you.

   They’ve put their heart and soul into creating this app, and it has
   some amazing features:
     * 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

   The problem is that you thought you requested a core product with a
   couple of extra features, if they were easy enough to implement.
   Meanwhile, the dev team heard something else. They heard about some
   exciting challenges they could tackle… and a slew of boring, basic
   features they couldn’t be bothered to test properly or care about.

   Even worse, you didn’t communicate directly with the devs — you
   communicated through a game of Telephone. You spoke to a sales guy, who
   held a meeting with some middle management chap, who wrote some
   business specs and gave those to a PM, who wrote some technical specs
   and gave those to a team lead or architect, who then, at last, began to
   design the product with his team — each one of them putting a bit of
   his own twist on it along the way.
     __________________________________________________________________

   Imaginary problems are often more fun to solve than real ones.
   Extremely intelligent people play competitive games, construct and
   solve math problems, and write books that aim to answer abstract
   questions about the human condition, all of them for free. A mediocre
   programmer, however, will probably charge you a fair amount to build a
   simple Android app. That’s not because mediocre programmers are harder
   to find than geniuses, but because the former activities are all fun,
   while the latter can be quite boring.

   Most programmers want to get paid and have fun at the same time. Of
   course, the definition of “fun” is different for everyone, but for many
   engineers, it boils down to tackling interesting and challenging
   problems that are within the realm of solvability.

   Give a somewhat intelligent person too many boring tasks that are
   impossible to automate and you will eventually drive him mad. The human
   brain however, after billions of years of evolution, is quite talented
   at keeping its sanity. 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.

   The amount of imaginary problems a software engineer can create for
   themselves is a function of their imagination and of the difficulty of
   the real problems they’re supposed to solve.

   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.

   When problems are dumb, intelligent individuals will find a way of
   coping.
     __________________________________________________________________

   But imaginary problems aren’t just the result of bored developers.
   They’re also the result of long chains of communication.

   When I first began taking on freelance clients, I couldn’t afford to be
   particular. This means I’ve had email chains lasting for over a 100
   exchanges, discussing insignificant details about internal MVPs. I’ve
   had people change every single requirement on a project within the span
   of a week. I’ve had clients ask questions such as “Could this be
   ICO-ed?” or “Can we add some A.I. in here?”

   Granted, most clients are savvier than that, but, even still, they
   often lack a bit of the knowledge necessary to articulate or construct
   some of their requirements. That is fine, as part of my job as “the
   computer guy” is to help people figure out what they do and don’t need
   based on their use cases. But it can become much harder to determine
   what’s needed when there are a few layers between you and the client.

     Requirements get changed because someone either misunderstood an
     intention or because someone was trying to cope with that
     aforementioned boredom

   Most companies like having a sales guy who pitches potential customers,
   negotiates prices, and outlines possible features. They also have a
   [6]people person to discuss more in-depth requirements and details with
   the customer, usually another sales guy, but with a slightly different
   title. Then there’s the internal chain of command, various levels of
   management, and possibly some hierarchy, within the technical team.

   When a list of client requirements goes through so many people, even if
   those people have the best of intentions, some things will inevitably
   get lost in translation. Sometimes that change happens because the
   original requirement made no sense, or sometimes requirements need to
   be redefined. The sales guy might have told the client, “for only
   39,999 extra we can do this on the Blockchain.” But that leaves
   everyone who encounters the requirements down the line wondering what
   the definition is of “doing it on the Blockchain.”

   More often than not, requirements get changed because someone either
   misunderstood an intention or because someone was trying to cope with
   that aforementioned boredom, trying to make his job or the work of his
   team more interesting and impressive.

   Through all of this, the original requirements — the real problems that
   have to be solved — get lost. They are replaced with imaginary problems
   and with voids, and you’ve got plenty of people ready and willing to
   fill those voids with their own imaginary problems, because the
   problems they have to solve are boring, and filling the voids gives
   them a way of coping.

Overcomplexity and natural selection

   There can often be an even darker reason for the existence of imaginary
   problems: problems can help a team or a company grow, and can even
   become an integral part of its function.

     “People who are bred, selected, and compensated to find complicated
     solutions do not have an incentive to implement simplified ones.”

     — Nassim Nicholas Taleb

   Have you ever heard about those three web engineers who figured out
   that secure online banking is actually quite an easy problem to solve?
   They developed some flawless banking software from scratch, using a
   functional design methodology and memory safe languages, then started
   migrating major banks to their amazing infrastructure.

   Probably you haven’t heard of them, because they don’t exist. There
   are, however, plenty of teams of [7]thousands of developers, who are
   unable to grasp simple concepts such “rollbacks,” perpetually creating
   banking software.

   The storage and transfer of numbers is not a particularly hard problem.
   Indexing the whole content of the internet and providing relevant
   results to natural language queries, in sub second times, is a hard
   problem. [8]But just a few smart guys managed to solve that problem.

   The persistent problem for online banking is that the banking ecosystem
   has become really good at preserving its own money-grabbing hierarchy.
   Its leaders are [9]corrupt leeches who prey on society — but the
   leaders in an organization are just a symptom of its members.

   I wouldn’t suggest that most underling workers for banks are evil or
   malicious in any way. Far from it. They are usually friendly lads,
   working to provide food, shelter, and an education for their families.
   But their chief incentive is not to fix the banking software, it is to
   stay employed. Losing your job in today’s economy is no joking matter
   for some; in the banking industry, a big mouth or too much initiative
   is an easy way find yourself in front of a disciplinary committee.

   So banking systems remain the same — not because the systems are
   efficient, but because of inertia. This inertia comes in the form of
   working on imaginary problems in order to avoid fixing real
   problems — real problems which, once pointed out, would threaten the
   jobs of other people. To focus on these real problems could lead to
   getting fired, or, in the case of some particularly nasty
   “institutions” like Goldman Sachs, [10]getting a few life-ruining brown
   envelopes sent to a few FBI officers and prompting a strange suicide.

     “It is difficult to get a man to understand something, when his
     salary depends upon his not understanding it!”

     — Upton Sinclair

   The [11]C-suite ignores the fact that their upper management workers
   spend 90 percent of their time on “client meetings” that involve
   tropical islands and million-dollar budgets for “other expenses.” Upper
   management, in return, turns a blind eye to corruption in C-suite.

   Because middle management encourages them to live in their Wolf of Wall
   Street fantasies, upper management ignores middle managers who buy
   eccentric offices and hire themselves three secretaries and a dozen
   interns.

   Because line management doesn’t complain about their dictatorial power
   fantasies, middle management ignores the fact that line managers,
   instead of cutting costs, spend their time working on PowerPoint
   presentations about “Improving our Agile Methodology.”

   Because the team leaders don’t seem to notice the fact that their
   superiors can’t even use Excel properly and only hit the office every
   few weeks, line managers ignore the team leaders and architects talking
   about “next generation interfacing between our systems using JRPC and
   microserviceization using Hibernate and Spring” when they should be
   getting those bloody Mysql queries to take less than a day.

   Because the developers don’t seem to notice that their leaders don’t
   really write any code except DOT diagrams, team leaders don’t complain
   about their developers, instead of looking at an EXPLAIN for the
   aforementioned slow query, re-designing the UI for the tenth time that
   year using a new JavaScript framework.

   It’s a vicious cycle of solving imaginary problems, from the CEO who
   doesn’t realize that stealing another 30 million won’t make his dad
   love him to the user-experience intern who doesn’t realize that
   redesigning the “submit” button using Angular-Material-Bootstrap
   19.13.5 won’t make the fact that they store passwords in plain text
   (and use them as part of the auth cookie) go away.

   But everyone needs to keep solving the imaginary problems, because if
   they stop creating and solving these problems, if they start focusing
   on the real problems, they might realize the whole system is broken.
   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. They might realize
   99 percent of their job is to perpetuate the existence of someone
   else’s job. And that’s a hard realization to digest—impossible for
   most, I dare say. So, instead, most find a way of coping.
     __________________________________________________________________

   If you enjoyed this article you may also like:
     * [12]The Red Queen
     * [13]Stop future proofing software

   Published on: 2019-04-29
     __________________________________________________________________

   ____________________ (BUTTON) Subscribe

   Reactions:

   angry
   loony
   pls
   sexy
   straigt-face
     __________________________________________________________________

   [14]twitter logo
   Share this article on twitter
   [15]linkedin logo
   Share this article on linkedin
   [16]Fb logo
   Share this article on facebook

References

   1. file:///feed.xml
   2. https://github.com/George3d6
   3. mailto:george@cerebralab.com
   4. https://twitter.com/Cerebralab2
   5. https://youtu.be/9jODhmgkp3o
   6. https://www.youtube.com/watch?v=hNuu9CpdjIo
   7. https://www.theguardian.com/business/2018/apr/28/warning-signs-for-tsbs-it-meltdown-were-clear-a-year-ago-insider
   8. https://en.wikipedia.org/wiki/History_of_Google
   9. https://en.wikipedia.org/wiki/Ben_Bernanke
  10. https://en.wikipedia.org/wiki/Sergey_Aleynikov
  11. https://www.investopedia.com/terms/c/c-suite.asp
  12. https://cerebralab.com/The Red Queen
  13. https://cerebralab.com/Stop future proofing software
  14. https://twitter.com/intent/tweet?text=A shameless content-promotion script has asked me to share with you this amazing article I just read: https://cerebralab.com
  15. https://www.linkedin.com/shareArticle?mini=true&url=https://cerebralab.com&summary=A shameless content-promotion script has asked me to share with you this amazing article I just read&source=https://cerebralab.com
  16. https://www.facebook.com/sharer/sharer.php?u=https://cerebralab.com
