cerebralab-com-qy5zqs.txt (16921B)
1 [book_front] [book_back] 2 night mode 3 [1][ ] Subscribe 4 5 [3] RSS 6 Add this blog to your rss feed 7 [4] github logo 8 Pollute your mind with some of my other missguided creations on Github 9 [5] email icon 10 Contact me at: [email protected] 11 [6] twitter logo 12 Publicly berate me on Twitter 13 14 This blog is no longer active, you can find my new stuff at: [7]george3d6.com, 15 [8]epistem.ink, [9]ontologi.cc, and [10]phenomenologi.cc 16 17 18 19 [11]Audio version (read by a tts bot) 20 21 Imaginary Problems Are the Root of Bad Software 22 23 https://upload.wikimedia.org/wikipedia/commons/c/c0/ 24 De_Rebus_Bellicis%2C_XVth_Century_Miniature.JPG There are many factors which 25 can be a catalyst for bad software: from the tools being used, to team 26 communication, to the personal stake developers have in its success, to the 27 testing methodology. 28 29 I propose that there is one problem chief among them, an impetus for bad 30 software from which almost all others take root: imaginary problems. 31 32 Most complicated or broken software is not designed to be overly complex or 33 dysfunctional. It’s just designed to do something other than its intended 34 purpose. 35 36 Let’s say you’re a podcast host who wants a custom website where you can sell 37 your promotional products, make advertising money without a third party cutting 38 in, and, most importantly, deliver podcasts, videos, and blogs to your 39 audience. 40 41 The requirements for your little web-app might look something like this: 42 43 • Fast load time in North America, with real-time podcast streaming and 44 downloads 45 • Doesn’t crash or freeze in the first 15 minutes for 99.99 percent of users, 46 preferably never crashes or freezes 47 • Integrates well with Google Adwords and maybe some other third-party ad 48 providers as well, if there’s time 49 • Dynamically links to the latest products in my Zazzle shop and, if 50 possible, gives recommendations to users based on the content they’ve 51 consumed 52 • Integrates with Facebook live player. If it’s easy to create an alternative 53 solution for streaming that doesn’t require Facebook, even better 54 55 You give these specs to a team of contractors, and you chat about them a bit. 56 It seems that everyone is on the same page. Yet, when they return with the 57 Minimum Viable Product two months later, your face turns red. You’ve just 58 wasted $15,000 on a piece of garbage; you want your money back. 59 60 The first time you open the app, the screen freezes. You ask how to select what 61 kind of ads should be allowed to run on the site and are pointed to an ugly, 62 hard-to-understand custom user interface (UI). Half the links to your 63 merchandise on Zazzle are broken or missing images, and the Facebook livestream 64 is laggy! 65 66 But the development team is confused at your anger — rightfully so, from their 67 point of view — because they’ve gone to hell and back for you. 68 69 They’ve put their heart and soul into creating this app, and it has some 70 amazing features: 71 72 • A state of the art recommendation system 73 • An algorithm generating the transcript of all your streams, in real time 74 • Your front page loads in sub 200ms times all over the world 75 • A streaming protocol and client build almost from scratch, in case you 76 don’t want to rely on Facebook live 77 • A service that allows you to easily integrate over 20 ad exchanges 78 79 The problem is that you thought you requested a core product with a couple of 80 extra features, if they were easy enough to implement. Meanwhile, the dev team 81 heard something else. They heard about some exciting challenges they could 82 tackle… and a slew of boring, basic features they couldn’t be bothered to test 83 properly or care about. 84 85 Even worse, you didn’t communicate directly with the devs — you communicated 86 through a game of Telephone. You spoke to a sales guy, who held a meeting with 87 some middle management chap, who wrote some business specs and gave those to a 88 PM, who wrote some technical specs and gave those to a team lead or architect, 89 who then, at last, began to design the product with his team — each one of them 90 putting a bit of his own twist on it along the way. 91 92 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 93 94 Imaginary problems are often more fun to solve than real ones. Extremely 95 intelligent people play competitive games, construct and solve math problems, 96 and write books that aim to answer abstract questions about the human 97 condition, all of them for free. A mediocre programmer, however, will probably 98 charge you a fair amount to build a simple Android app. That’s not because 99 mediocre programmers are harder to find than geniuses, but because the former 100 activities are all fun, while the latter can be quite boring. 101 102 Most programmers want to get paid and have fun at the same time. Of course, the 103 definition of “fun” is different for everyone, but for many engineers, it boils 104 down to tackling interesting and challenging problems that are within the realm 105 of solvability. 106 107 Give a somewhat intelligent person too many boring tasks that are impossible to 108 automate and you will eventually drive him mad. The human brain however, after 109 billions of years of evolution, is quite talented at keeping its sanity. Much 110 like victims of childhood hardship or abuse can find escape in fantasy books, 111 victims of enterprise programming or freelance web development can find their 112 escape in solving imaginary problems. 113 114 [1] 115 116 The amount of imaginary problems a software engineer can create for themselves 117 is a function of their imagination and of the difficulty of the real problems 118 they’re supposed to solve. 119 120 It should be noted that this issue isn’t unique to developers. Management, 121 sales, HR, support, legal, and even accounting departments have their own 122 unique ways of creating imaginary problems. They try to involve themselves too 123 much in a decision, when their presence at a meeting is just a formality or 124 wasn’t requested at all. They overemphasize a minute problem that is related to 125 their role, or hire teams much larger than necessary to illustrate their 126 importance. 127 128 When problems are dumb, intelligent individuals will find a way of coping. 129 130 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 131 132 But imaginary problems aren’t just the result of bored developers. They’re also 133 the result of long chains of communication. 134 135 When I first began taking on freelance clients, I couldn’t afford to be 136 particular. This means I’ve had email chains lasting for over a 100 exchanges, 137 discussing insignificant details about internal MVPs. I’ve had people change 138 every single requirement on a project within the span of a week. I’ve had 139 clients ask questions such as “Could this be ICO-ed?” or “Can we add some A.I. 140 in here?” 141 142 Granted, most clients are savvier than that, but, even still, they often lack a 143 bit of the knowledge necessary to articulate or construct some of their 144 requirements. That is fine, as part of my job as “the computer guy” is to help 145 people figure out what they do and don’t need based on their use cases. But it 146 can become much harder to determine what’s needed when there are a few layers 147 between you and the client. 148 149 Requirements get changed because someone either misunderstood an intention 150 or because someone was trying to cope with that aforementioned boredom 151 152 Most companies like having a sales guy who pitches potential customers, 153 negotiates prices, and outlines possible features. They also have a [12]people 154 person to discuss more in-depth requirements and details with the customer, 155 usually another sales guy, but with a slightly different title. Then there’s 156 the internal chain of command, various levels of management, and possibly some 157 hierarchy, within the technical team. 158 159 When a list of client requirements goes through so many people, even if those 160 people have the best of intentions, some things will inevitably get lost in 161 translation. Sometimes that change happens because the original requirement 162 made no sense, or sometimes requirements need to be redefined. The sales guy 163 might have told the client, “for only 39,999 extra we can do this on the 164 Blockchain.” But that leaves everyone who encounters the requirements down the 165 line wondering what the definition is of “doing it on the Blockchain.” 166 167 More often than not, requirements get changed because someone either 168 misunderstood an intention or because someone was trying to cope with that 169 aforementioned boredom, trying to make his job or the work of his team more 170 interesting and impressive. 171 172 Through all of this, the original requirements — the real problems that have to 173 be solved — get lost. They are replaced with imaginary problems and with voids, 174 and you’ve got plenty of people ready and willing to fill those voids with 175 their own imaginary problems, because the problems they have to solve are 176 boring, and filling the voids gives them a way of coping. 177 178 Overcomplexity and natural selection 179 180 There can often be an even darker reason for the existence of imaginary 181 problems: problems can help a team or a company grow, and can even become an 182 integral part of its function. 183 184 “People who are bred, selected, and compensated to find complicated 185 solutions do not have an incentive to implement simplified ones.” 186 187 — Nassim Nicholas Taleb 188 189 Have you ever heard about those three web engineers who figured out that secure 190 online banking is actually quite an easy problem to solve? They developed some 191 flawless banking software from scratch, using a functional design methodology 192 and memory safe languages, then started migrating major banks to their amazing 193 infrastructure. 194 195 Probably you haven’t heard of them, because they don’t exist. There are, 196 however, plenty of teams of [13]thousands of developers, who are unable to 197 grasp simple concepts such “rollbacks,” perpetually creating banking software. 198 199 The storage and transfer of numbers is not a particularly hard problem. 200 Indexing the whole content of the internet and providing relevant results to 201 natural language queries, in sub second times, is a hard problem. [14]But just 202 a few smart guys managed to solve that problem. 203 204 The persistent problem for online banking is that the banking ecosystem has 205 become really good at preserving its own money-grabbing hierarchy. Its leaders 206 are [15]corrupt leeches who prey on society — but the leaders in an 207 organization are just a symptom of its members. 208 209 I wouldn’t suggest that most underling workers for banks are evil or malicious 210 in any way. Far from it. They are usually friendly lads, working to provide 211 food, shelter, and an education for their families. But their chief incentive 212 is not to fix the banking software, it is to stay employed. Losing your job in 213 today’s economy is no joking matter for some; in the banking industry, a big 214 mouth or too much initiative is an easy way find yourself in front of a 215 disciplinary committee. 216 217 So banking systems remain the same — not because the systems are efficient, but 218 because of inertia. This inertia comes in the form of working on imaginary 219 problems in order to avoid fixing real problems — real problems which, once 220 pointed out, would threaten the jobs of other people. To focus on these real 221 problems could lead to getting fired, or, in the case of some particularly 222 nasty “institutions” like Goldman Sachs, [16]getting a few life-ruining brown 223 envelopes sent to a few FBI officers and prompting a strange suicide. 224 225 “It is difficult to get a man to understand something, when his salary 226 depends upon his not understanding it!” 227 228 — Upton Sinclair 229 230 The [17]C-suite ignores the fact that their upper management workers spend 90 231 percent of their time on “client meetings” that involve tropical islands and 232 million-dollar budgets for “other expenses.” Upper management, in return, turns 233 a blind eye to corruption in C-suite. 234 235 Because middle management encourages them to live in their Wolf of Wall Street 236 fantasies, upper management ignores middle managers who buy eccentric offices 237 and hire themselves three secretaries and a dozen interns. 238 239 Because line management doesn’t complain about their dictatorial power 240 fantasies, middle management ignores the fact that line managers, instead of 241 cutting costs, spend their time working on PowerPoint presentations about 242 “Improving our Agile Methodology.” 243 244 Because the team leaders don’t seem to notice the fact that their superiors 245 can’t even use Excel properly and only hit the office every few weeks, line 246 managers ignore the team leaders and architects talking about “next generation 247 interfacing between our systems using JRPC and microserviceization using 248 Hibernate and Spring” when they should be getting those bloody Mysql queries to 249 take less than a day. 250 251 Because the developers don’t seem to notice that their leaders don’t really 252 write any code except DOT diagrams, team leaders don’t complain about their 253 developers, instead of looking at an EXPLAIN for the aforementioned slow query, 254 re-designing the UI for the tenth time that year using a new JavaScript 255 framework. 256 257 It’s a vicious cycle of solving imaginary problems, from the CEO who doesn’t 258 realize that stealing another 30 million won’t make his dad love him to the 259 user-experience intern who doesn’t realize that redesigning the “submit” button 260 using Angular-Material-Bootstrap 19.13.5 won’t make the fact that they store 261 passwords in plain text (and use them as part of the auth cookie) go away. 262 263 But everyone needs to keep solving the imaginary problems, because if they stop 264 creating and solving these problems, if they start focusing on the real 265 problems, they might realize the whole system is broken. They might realize 266 Debra has been sitting in that corner, staring at uptime graphs of the internal 267 server farm for 10 years, despite the fact that the company moved to AWS five 268 years ago. They might realize 99 percent of their job is to perpetuate the 269 existence of someone else’s job. And that’s a hard realization to 270 digest—impossible for most, I dare say. So, instead, most find a way of coping. 271 272 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 273 274 If you enjoyed this article you may also like: 275 276 • [18]The Red Queen 277 • [19]Stop future proofing software 278 279 Published on: 2019-04-29 280 281 282 283 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 284 285 286 [20][ ] Subscribe 287 288 289 290 291 Reactions: 292 293 angry 294 loony 295 pls 296 sexy 297 straigt-face 298 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 299 [22] twitter logo 300 Share this article on twitter 301 [23] linkedin logo 302 Share this article on linkedin 303 [24] Fb logo 304 Share this article on facebook 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 References: 322 323 [3] https://cerebralab.com/feed.xml 324 [4] https://github.com/George3d6 325 [5] mailto:[email protected] 326 [6] https://twitter.com/Cerebralab2 327 [7] https://george3d6.com/ 328 [8] https://epistem.ink/ 329 [9] https://ontologi.cc/ 330 [10] https://phenomenologi.cc/ 331 [11] https://youtu.be/9jODhmgkp3o 332 [12] https://www.youtube.com/watch?v=hNuu9CpdjIo 333 [13] https://www.theguardian.com/business/2018/apr/28/warning-signs-for-tsbs-it-meltdown-were-clear-a-year-ago-insider 334 [14] https://en.wikipedia.org/wiki/History_of_Google 335 [15] https://en.wikipedia.org/wiki/Ben_Bernanke 336 [16] https://en.wikipedia.org/wiki/Sergey_Aleynikov 337 [17] https://www.investopedia.com/terms/c/c-suite.asp 338 [18] https://cerebralab.com/The%20Red%20Queen 339 [19] https://cerebralab.com/Stop%20future%20proofing%20software 340 [22] https://twitter.com/intent/tweet?text=A%20shameless%20content-promotion%20script%20has%20asked%20me%20to%20share%20with%20you%20this%20amazing%20article%20I%20just%20read:%20https://cerebralab.com 341 [23] https://www.linkedin.com/shareArticle?mini=true&url=https://cerebralab.com&summary=A%20shameless%20content-promotion%20script%20has%20asked%20me%20to%20share%20with%20you%20this%20amazing%20article%20I%20just%20read&source=https://cerebralab.com 342 [24] https://www.facebook.com/sharer/sharer.php?u=https://cerebralab.com