323 lines
16 KiB
Plaintext
323 lines
16 KiB
Plaintext
[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
|