-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
1045 lines (946 loc) · 47.8 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Choose Boring Technology</title>
<link rel="stylesheet" href="presentation.css">
<meta charset="utf-8">
<meta content="IE=edge" http-equiv="X-UA-Compatible">
<meta content="width=device-width, height=device-height, initial-scale=1" name="viewport">
</head>
<body>
<h3 class="club-index"><a href="http://dotclub.club">The .club Club</a></h3>
<header>
<h1>Choose Boring Technology</h1>
<p>
This is the spoken word version of my essay, <a href="http://mcfunley.com/choose-boring-technology">Choose Boring Technology</a>. I have largely come to terms with it and the reality that I will never escape its popularity. </p>
<p>
I gave this most recently at the WikiMedia Foundation’s developer conference, where <a href="https://twitter.com/cscottnet">Scott Ananian</a> called it “how to be old, for young people.”
</p>
<p>
Here are <a href="https://dotclub.club">my other talks</a> and <a href="http://mcfunley.com">my website</a>.
</p>
<p>
正體中文翻譯在 <a href="./index_zh_TW.html">這裡</a>
</p>
<div class="share">
<a class="bsky" href="https://bsky.app/profile/mcfunley.com">
<svg fill="none" viewBox="0 0 64 57" width="28" style="width: 28px; height: 24.9375px;"><path fill="#0085ff" d="M13.873 3.805C21.21 9.332 29.103 20.537 32 26.55v15.882c0-.338-.13.044-.41.867-1.512 4.456-7.418 21.847-20.923 7.944-7.111-7.32-3.819-14.64 9.125-16.85-7.405 1.264-15.73-.825-18.014-9.015C1.12 23.022 0 8.51 0 6.55 0-3.268 8.579-.182 13.873 3.805ZM50.127 3.805C42.79 9.332 34.897 20.537 32 26.55v15.882c0-.338.13.044.41.867 1.512 4.456 7.418 21.847 20.923 7.944 7.111-7.32 3.819-14.64-9.125-16.85 7.405 1.264 15.73-.825 18.014-9.015C62.88 23.022 64 8.51 64 6.55c0-9.818-8.578-6.732-13.873-2.745Z"></path></svg>
<span class="handle">@mcfunley.com</span>
</a>
</div>
</div>
</header>
<div class="presentation">
<table class="slides">
<tr>
<td class="slide">
<img src="slides/slides.001.jpeg" />
</td>
<td class="note">
<a name="1"></a>
<a href="#1">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.002.jpeg" />
</td>
<td class="note">
<a name="2"></a>
Hey
<a href="#2">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.003.jpeg" />
</td>
<td class="note">
<a name="3"></a>
I’m Dan McKinley. That’s me in the hole. It’s a metaphor.
<a href="#3">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.004.jpeg" />
</td>
<td class="note">
<a name="4"></a>
I work for a company called Mailchimp, or Mailkimp if you listen to podcasts. I was an early employee at Etsy, and that was a formative experience for me, so I’ll refer to my time there a lot. But I’ve worked for a few other places since.
<a href="#4">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.005.jpeg" />
</td>
<td class="note">
<a name="5"></a>
I’ve worked at big companies and at smaller ones, and at my own tiny startups. I’ve noticed a few things.<br /><br />Big companies can have a branded way of doing engineering. For example, “The Etsy Way” of doing engineering became a thing. Living inside of that box where your needs are met and questions are answered can spoil you somewhat. <br /><br />But I’ve also been in situations where “the way engineering is done” is actively being figured out, or in periods of transition. And in those situations I’ve had to ponder a couple of questions.
<a href="#5">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.006.jpeg" />
</td>
<td class="note">
<a name="6"></a>
First, how do you pick the tools you’re going to use to get your work done?<br />
<a href="#6">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.007.jpeg" />
</td>
<td class="note">
<a name="7"></a>
Another question I care about is: how do you make developers happy? This matters to me, as a developer. I would like to be happy, if possible.
<a href="#7">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.008.jpeg" />
</td>
<td class="note">
<a name="8"></a>
If you go up to a developer and say, “hey, what would make you happy?” you often get highly specific answers. “I would be happy if I could write Clojure at work,” they’ll say, “so you should let me do my work in Clojure.” I don’t discount that when they do this, developers are genuinely describing some kind of endorphin-rich experience they have had at some point.<br /><br />However, I am skeptical that the state that they’re describing is the highest level of spiritual attainment possible.
<a href="#8">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.009.jpeg" />
</td>
<td class="note">
<a name="9"></a>
But I, too, was once like this.
<a href="#9">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.010.jpeg" />
</td>
<td class="note">
<a name="10"></a>
Etsy for example, early on, was a big ball of PHP spaghetti. It was written by someone that was unfortunately learning PHP as he was writing it. <br /><br />I spent several years just trying to avoid dealing with it. At one point I tried building Scala services that talked to MongoDB. I thought this would result in better infrastructure, solve all of my productivity problems, and would make me happy. But no part of that turned out to be the case. <br /><br />The embarrassing wreckage of this period is still on the internet, you can go find it and make fun of me. And Etsy employees still give me shit about it, with good cause.
<a href="#10">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.011.jpeg" />
</td>
<td class="note">
<a name="11"></a>
When I had my own startup last, I did use Clojure. I don’t think that Clojure is the reason, but I should disclaim here that that startup is no longer in business. <br /><br />Anyway I want to offer these anecdotes as my non-luddite bona fides. I am not someone that has never experienced the joy of functional programming. <br /><br />You don’t need to @ me to talk about Scala or Haskell. You certainly don’t need to do that with a rebuttal taking all of this extremely personally, even though I haven’t even mentioned you or those languages at all, Steve.
<a href="#11">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.012.jpeg" />
</td>
<td class="note">
<a name="12"></a>
But anyway, despite that, I’m mostly not a tool-obsessed engineer. My other talks are barely even about engineering. <br />
<a href="#12">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.013.jpeg" />
</td>
<td class="note">
<a name="13"></a>
I don’t think I’ve become that way because I’ve gotten old and cranky. Although I am certainly those things, I think I’ve gotten perspective on this by summiting Maslow’s hierarchy at some point in my past.<br /><br />Maslow’s hierarchy, briefly, is the idea that you have to satisfy your more basic needs before higher levels of intellectual fulfillment are possible. You can’t do poetry if you’re worried about what you’re going to eat today. <br />
<a href="#13">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.014.jpeg" />
</td>
<td class="note">
<a name="14"></a>
We can look to the case of Siegfried Sassoon and ponder whether this is the case or not for poetry, but I think it's mostly true in software. You can’t worry about the big picture and ask intelligent questions about the direction of the product if you’re busy arguing about which database or alerting system to use.<br /><br />I’ve been pretty lucky to have been in situations where those basic needs were fulfilled. And I want to help get others to this state.
<a href="#14">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.015.jpeg" />
</td>
<td class="note">
<a name="15"></a>
An important step in getting to that state is realizing that attention is precious.<br /><br />Humans have a finite amount of capacity for sweating details.
<a href="#15">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.016.jpeg" />
</td>
<td class="note">
<a name="16"></a>
My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else.<br /><br />I don’t know if this makes sense for fashion or what have you, but I really think there is something to this.
<a href="#16">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.017.jpeg" />
</td>
<td class="note">
<a name="17"></a>
I like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. This is a purely fictional construct I just made up, and my ICO goes on sale next week.<br /><br />These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that.
<a href="#17">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.018.jpeg" />
</td>
<td class="note">
<a name="18"></a>
So what’s your company trying to do? Well, Etsy, where I used to work, used to make the claim that it was trying to reshape the entire world economy.<br /><br />Now I don’t know the extent to which we should take tech company missions seriously. I am beginning to suspect that we should not take them seriously at all. <br /><br />But let’s be naive for a minute, and consider the implications that would result if they really wanted to do this.
<a href="#18">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.019.jpeg" />
</td>
<td class="note">
<a name="19"></a>
Reshaping the entire world economy sounds like a big job. And that probably costs at least one of your tokens.
<a href="#19">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.020.jpeg" />
</td>
<td class="note">
<a name="20"></a>
A company I worked at after Etsy is trying to “increase the GDP of the internet.”
<a href="#20">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.021.jpeg" />
</td>
<td class="note">
<a name="21"></a>
Again, that sounds like a pretty complicated thing to be doing. We probably have to spend at least one of our tokens on that. Maybe two. Maybe all of them!
<a href="#21">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.022.jpeg" />
</td>
<td class="note">
<a name="22"></a>
If you think about innovation as a scarce resource, it starts to make less sense to also be on the front lines of innovating on databases. Or on programming paradigms. <br /><br />The point isn’t that these things can’t work. Of course they can work. And there are many examples of them actually working. <br /><br />But software that’s been around longer tends to need less care and feeding than software that just came out.
<a href="#22">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.023.jpeg" />
</td>
<td class="note">
<a name="23"></a>
To get at the reason for that I want to talk about the philosophy of knowledge a little bit. What can we know about a piece of technology? This is not actually a frivolous question. It’s really important.
<a href="#23">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.024.jpeg" />
</td>
<td class="note">
<a name="24"></a>
I hate Donald Rumsfeld, and I hope he fries. But he’s associated with the following, which is thoroughly relevant to our subject. So I feel like I have to acknowledge his demonic presence long enough to distance myself from him.
<a href="#24">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.025.jpeg" />
</td>
<td class="note">
<a name="25"></a>
When we don’t know something, there are really two different categories that that lack of knowledge can be in.<br /><br />There are known unknowns, that is, things that we know that we don’t know. And there are unknown unknowns, things that we don’t know and that we don’t know that we don’t know.
<a href="#25">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.026.jpeg" />
</td>
<td class="note">
<a name="26"></a>
This applies in technology. This is an example of a known unknown. For a given database, we might not know what happens when a network partition occurs. But we know that a network partition is possible. Since we know that this is possible, we can test for this. Or we can just cross our fingers and hope that it doesn’t happen. Either way, we are informed about the possibility.
<a href="#26">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.027.jpeg" />
</td>
<td class="note">
<a name="27"></a>
There are also unknown unknowns in technology. This is a random example I saw a while back. This person spent four months trying to figure out why he was getting GC pauses, and it turned out to be because he was writing stats to a file. He had no idea that that was a thing that could happen, but it was.<br /><br />Many bugs in software are like that. We don’t know they’re there, and we don’t even really know we should be on the lookout for them. They’re unknown unknowns.
<a href="#27">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.028.jpeg" />
</td>
<td class="note">
<a name="28"></a>
Now, it’s important to realize that both categories are present in all software. Software that’s 10 years old generally comes with a JIRA instance full of tickets describing broken stuff that nobody’s ever going to fix. And then there are always bugs that nobody knows about, even in software that’s been around forever.
<a href="#28">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.029.jpeg" />
</td>
<td class="note">
<a name="29"></a>
But it’d be wrong to say that all technology is therefore equivalent. New technology has a larger cardinality for both of these sets. <br /><br />New tech typically has more known unknowns, and many more unknown unknowns. And this is really important.
<a href="#29">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.030.jpeg" />
</td>
<td class="note">
<a name="30"></a>
I chose “boring technology” as the pithy SEO-friendly title for this content, and I regret it most days. It’s kind of distracting. “Boring sounds bad, why is he saying it’s good?” Et cetera. It’s a real shitshow.<br /><br />But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down.
<a href="#30">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.031.jpeg" />
</td>
<td class="note">
<a name="31"></a>
So, ok, all you have to do is use Postgres, and you’re all set, right? Well, no. Unfortunately the combination of things that you choose also matters.
<a href="#31">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.032.jpeg" />
</td>
<td class="note">
<a name="32"></a>
Let’s say that you’re already using this stack. You have Python, Memcached, MySQL, and Apache.
<a href="#32">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.033.jpeg" />
</td>
<td class="note">
<a name="33"></a>
Let’s say you have a new problem to solve. Do you think it makes sense to add Ruby to your existing stack?
<a href="#33">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.034.jpeg" />
</td>
<td class="note">
<a name="34"></a>
The intuition of nearly everyone with any seasoning on them at all is “uh, geez, probably not.” <br /><br />We know that the marginal utility of adding ruby isn’t going to outweigh the complexity hit we take by adding it. Python and Ruby are pretty much the same thing.
<a href="#34">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.035.jpeg" />
</td>
<td class="note">
<a name="35"></a>
Ok, so how about adding Redis? We already have MySQL and Memcached, but should we add Redis?
<a href="#35">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.036.jpeg" />
</td>
<td class="note">
<a name="36"></a>
In my experience it is about here where the wheels come off. People lose their shit and start beating their polyglot programmer drums. There’s something about the idea of adding a new database that has people storming the Bastille, saying “you can’t stop us from using the best tool for the job, man.”<br /> <br />And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is.
<a href="#36">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.037.jpeg" />
</td>
<td class="note">
<a name="37"></a>
What are we actually doing? Let’s dig in.
<a href="#37">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.038.jpeg" />
</td>
<td class="note">
<a name="38"></a>
This is what we’re implicitly saying when we want to add a piece of semi-redundant technology. <br /><br />We’re saying that the new tech is going to make our work so much easier in the near term that this benefit outweighs the cost of dealing with that technology indefinitely into the future.
<a href="#38">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.039.jpeg" />
</td>
<td class="note">
<a name="39"></a>
That’s not a very complicated premise. We can try to apply structured thinking to it.
<a href="#39">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.040.jpeg" />
</td>
<td class="note">
<a name="40"></a>
Backing up a bit, your job is what my friend Coda says, here. You’re supposed to be solving business problems with technology.
<a href="#40">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.041.jpeg" />
</td>
<td class="note">
<a name="41"></a>
We’re in a field that allegedly has something to do with computer science, so we can pretend to be computer scientists for a minute here and model this situation as a bipartite graph. <br /><br />On the left side we have business problems, and on the right side we have technical solutions.
<a href="#41">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.042.jpeg" />
</td>
<td class="note">
<a name="42"></a>
We have to try to connect all of the nodes on the left side so that our problems are solved. Adding an edge here is making a technology choice.
<a href="#42">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.043.jpeg" />
</td>
<td class="note">
<a name="43"></a>
Every choice has a maintenance cost, but we also get the benefit of the technology that we choose. We solve the problem, we have capacity for solving additional problems, whatever.
<a href="#43">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.044.jpeg" />
</td>
<td class="note">
<a name="44"></a>
So we have a nonzero benefit, and a nonzero cost for every choice.
<a href="#44">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.045.jpeg" />
</td>
<td class="note">
<a name="45"></a>
When we add more than one edge, we can make a choice. We can use the same technology that we’ve already paid for …
<a href="#45">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.046.jpeg" />
</td>
<td class="note">
<a name="46"></a>
Or we could pick a different piece of technology. We have to pay for that new tech, too, but maybe we get so much development velocity or endorphins that it’s worth it.
<a href="#46">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.047.jpeg" />
</td>
<td class="note">
<a name="47"></a>
We’re trying to minimize this cost function. The total cost of our operations is all of the maintenance costs we take on from our choices, minus the development velocity and what-have-yous that we get from every choice.
<a href="#47">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.048.jpeg" />
</td>
<td class="note">
<a name="48"></a>
The way we behave really depends on what you believe about which term dominates this equation in the real world.<br /><br />If technology is really expensive to operate, the costs dominate. If technology really makes a huge difference in how easy your job is, the benefits dominate.
<a href="#48">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.049.jpeg" />
</td>
<td class="note">
<a name="49"></a>
So, depending, you might decide to make an allocation like this. Here we’ve picked many different technologies to use to solve all of our problems.
<a href="#49">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.050.jpeg" />
</td>
<td class="note">
<a name="50"></a>
And that makes complete sense if each additional technology choice is cheap.<br />
<a href="#50">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.051.jpeg" />
</td>
<td class="note">
<a name="51"></a>
This is an alternative strategy. Here we’ve chosen just a few technologies that cover our domain, and solved all of our problems with them.
<a href="#51">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.052.jpeg" />
</td>
<td class="note">
<a name="52"></a>
And that’s what we should do if we think that each technology we add comes with a lot of baggage.
<a href="#52">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.053.jpeg" />
</td>
<td class="note">
<a name="53"></a>
Here in reality, new technology choices come with a great deal of baggage.
<a href="#53">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.054.jpeg" />
</td>
<td class="note">
<a name="54"></a>
This is reality. Costs to operate a technology in perpetuity tend to outstrip the convenience you get by using something different.
<a href="#54">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.055.jpeg" />
</td>
<td class="note">
<a name="55"></a>
So this tends to be the right way to arrange things. We should generally pick the smallest set of tech that covers our problem domain, and lets us get the job done.
<a href="#55">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.056.jpeg" />
</td>
<td class="note">
<a name="56"></a>
That’s the case because operating a piece of technology at a professional level turns out to be really hard. It’s easy to get started with a lot of technology, but harder to do a really good job with it.
<a href="#56">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.057.jpeg" />
</td>
<td class="note">
<a name="57"></a>
This is why. Adding the technology is easy, living with it is hard. These are all the things you have to worry about.<br /><br />I could brew install a new database right here right now while giving this talk, and start writing some data to it. God help me I could, don’t make me do it. But it’s another matter entirely to run that thing in production at a professional level.
<a href="#57">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.058.jpeg" />
</td>
<td class="note">
<a name="58"></a>
So polyglot persistence is not the kind of freedom we are looking for, and honestly I wish Martin Fowler would just take the damn bliki about it down already.<br /><br />If you’re giving individual teams (or gods help you, individuals) free reign to make local decisions about infrastructure, you’re hurting yourself globally. <br /><br />It’s freedom, sure. You’re handing developers a ball of chain and padlocks and telling them to feel free to bind themselves to the operational toil that will be with them until the sweet release of grim death.
<a href="#58">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.059.jpeg" />
</td>
<td class="note">
<a name="59"></a>
It gets worse. There’s more to this than just avoiding duplication of effort, and an excess of operational overhead. By embracing polyglot persistence, you’re also discarding real, positive benefits that only arise when everyone’s using a shared platform.
<a href="#59">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.060.jpeg" />
</td>
<td class="note">
<a name="60"></a>
A good example of this from my past is Etsy’s activity feeds.<br /><br />Twitter is/was an activity feed, Facebook’s newsfeed is one too. Etsy spent many years dabbling in VC funding and coincidentally I guess also wanted a feed just like theirs. <br /><br />I built this with a small team back in 2010. It was pretty fun.
<a href="#60">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.061.jpeg" />
</td>
<td class="note">
<a name="61"></a>
Here’s a totally reasonable way to build activity feeds, if that’s all you’re trying to do. You get events from the outside world, then you write them to a database. Then an offline process comes along and aggregates those, sprinkles some machine learning on things, and stuffs a materialized newsfeed into a thing like Redis for serving frontend traffic. This would totally work great.
<a href="#61">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.062.jpeg" />
</td>
<td class="note">
<a name="62"></a>
But when we set out to build activity feeds, we didn’t have Redis. We did have Memcached. They’re sort of similar in the sense that you can shove a blob in them, and get it back out with a similar API. But they have very different guarantees. The most relevant difference to us here is that Redis is persistent, and Memcached is ephemeral.<br />
<a href="#62">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.063.jpeg" />
</td>
<td class="note">
<a name="63"></a>
What that means is that if you want to build an activity feed with Memcached, you have to do a bunch of extra work. You have to cope with the possibility that Memcached has gotten rid of your data at the moment you want it. <br /><br />That creates a ton more work when it comes to writing the code to deliver the feature. But we weighed that against the persistent cost of operating a new kind of database, and decided that we’d bite the bullet and build the feature on Memcached.<br />
<a href="#63">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.064.jpeg" />
</td>
<td class="note">
<a name="64"></a>
Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it.
<a href="#64">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.065.jpeg" />
</td>
<td class="note">
<a name="65"></a>
Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprised to discover that in the time since we’d launched it, the usage had increased by a factor of 20. And as far as I could tell it was totally fine.<br /><br />The fact that 2,000% more people could be using activity feeds and we didn’t even have any idea that it was happening is certainly the greatest purely technical achievement of my career.
<a href="#65">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.066.jpeg" />
</td>
<td class="note">
<a name="66"></a>
The reason it was possible was because we used the shared stack. There were people around whose job involved noticing that we needed more MySQL’s or cron boxes or whatever. And there were other people who had to go to the datacenter and plug in new machines. But they were doing that horizontal scaling because the site was growing holistically. Nobody doing this had any awareness of our lone feature.<br />
<a href="#66">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.067.jpeg" />
</td>
<td class="note">
<a name="67"></a>
If we’d deployed Redis just for activity feeds, you can be sure that Redis would have become distressed at some point as the feature scaled up 20 times. And we would have had to go back and work on Redis just to keep activity feeds working.
<a href="#67">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.068.jpeg" />
</td>
<td class="note">
<a name="68"></a>
Or more likely, someone else would have had to do it. Our team didn’t exist at all a year later, we were all working on different things. <br /><br />Something I have noticed is that people like cleaning up my messes even less than they like cleaning up their own messes. So this would have gotten awkward and terrible for everyone.
<a href="#68">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.069.jpeg" />
</td>
<td class="note">
<a name="69"></a>
So I’m making a case here that you should tend to prefer mature things, and you should try not to use too many things.<br /><br />But it’s not an absolute principle. Obviously sometimes it does make sense to add new technology to your stack. And it can even make sense to use a weird new thing. <br />
<a href="#69">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.070.jpeg" />
</td>
<td class="note">
<a name="70"></a>
So I wanted to talk a bit about how you might go about doing that.
<a href="#70">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.071.jpeg" />
</td>
<td class="note">
<a name="71"></a>
The long and short of it is that you have to talk to each other. <br /><br />Technology has global effects on your company, it isn’t something that should be left to individual engineers. You have to figure out a way to make adding technology a conversation.<br /><br />This might be underwhelming if you were expecting a big insightful secret here, but trust me, this is beyond many technology organizations. <br />
<a href="#71">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.072.jpeg" />
</td>
<td class="note">
<a name="72"></a>
Let’s say you’ve succeeded in gatekeeping new pieces of technology with a conversation. <br /><br />An excellent first question in such a conversation is: “how would we solve the problem at hand without adding anything new?”
<a href="#72">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.073.jpeg" />
</td>
<td class="note">
<a name="73"></a>
This is a great question to ask because it immediately identifies the situation in which the problem is that we’d like to use a new piece of technology. “Um the problem is that we don’t use Cassandra but maybe we could.” That kind of thing. If you identify this situation, that’s great, because you can immediately stop talking about it.<br /><br />
<a href="#73">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.074.jpeg" />
</td>
<td class="note">
<a name="74"></a>
But anyway, assuming that you have a real problem, the answer is rarely that you can’t do it. If you have a functioning service of any complexity in production already, and you think you can’t accomplish a specific new feature with what you’ve already have, you’re probably just not thinking hard enough. <br /><br />You may need to resort to unnatural acts, but you can get pretty far with a minimal stack.
<a href="#74">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.075.jpeg" />
</td>
<td class="note">
<a name="75"></a>
It’s really worthwhile to actually write down what all of the awkward things you’d have to do are. A lot of the time when you do this, you realize that the situation isn’t really that bad. Or it may be bad, but not as bad as the task of operationalizing a new thing. <br /><br />But it can go the other way, too. You can list all of the unnatural acts and conclude that adding a new thing will be worth it.
<a href="#75">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.076.jpeg" />
</td>
<td class="note">
<a name="76"></a>
And if you decide to try out a new piece of technology, you should figure out low-risk ways to get started. Your tactic should not be to rewrite your entire application with it in one step. You should be proving the technology in production with minimal risk, and then gradually gaining confidence in it.
<a href="#76">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.077.jpeg" />
</td>
<td class="note">
<a name="77"></a>
If you’re adding a redundant piece of technology, your goal is to replace something with it. Your goal shouldn’t be to operate two pieces of technology that are redundant with one another forever. <br /><br />When you add a thing that replaces another thing, you should be committing to a plan to replace the old thing. It might be a long term plan. And you should be committing to rewriting the new thing using the old tools if the new tools don’t actually work out.
<a href="#77">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.078.jpeg" />
</td>
<td class="note">
<a name="78"></a>
So, in closing
<a href="#78">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.079.jpeg" />
</td>
<td class="note">
<a name="79"></a>
This is what you should do, most of the time. Prefer technology that’s well understood, with failure modes that are known.
<a href="#79">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.080.jpeg" />
</td>
<td class="note">
<a name="80"></a>
Prefer things that let you focus your attention on what really matters.
<a href="#80">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.081.jpeg" />
</td>
<td class="note">
<a name="81"></a>
Think about what you’re doing holistically, and pick a few tools that cover your entire problem domain and solve all of your problems with them. <br /><br />The interesting thing here is that none of the tools that you pick may be the “right tool” for any given job. But they can still be the right choice for the total set of jobs.
<a href="#81">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.082.jpeg" />
</td>
<td class="note">
<a name="82"></a>
It’s important to master the tools that you do pick.
<a href="#82">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.083.jpeg" />
</td>
<td class="note">
<a name="83"></a>
I have noticed that every piece of software obeys this law. When you first start using it, it’s awful. It’s awful because you find all of the problems.
<a href="#83">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.084.jpeg" />
</td>
<td class="note">
<a name="84"></a>
If you are naive, you put a new thing into production, and experience this law in practice. And then you conclude from this that you should use a different thing for the next feature. <br /><br />This is how you awoke one morning, from uneasy dreams probably, and found yourself with nine alerting systems in production.<br /><br />The new thing won’t be better, you just aren’t aware of all of the ways it will be terrible yet.
<a href="#84">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.085.jpeg" />
</td>
<td class="note">
<a name="85"></a>
If you behave that way you miss out on the part of the curve that we call “mastery.” That’s a state to the right on this curve, where there are still problems. Everything still sucks but it feels manageable.<br /><br />The grim paradox of this law of software is that you should probably be using the tool that you hate the most. You hate it because you know the most about it.
<a href="#85">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.086.jpeg" />
</td>
<td class="note">
<a name="86"></a>
You should have a process for adding technology to your stack that involves talking to other humans.
<a href="#86">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.087.jpeg" />
</td>
<td class="note">
<a name="87"></a>
You should be trying to climb up Maslow’s hierarchy, and worrying about the big picture. You shouldn’t be arguing about what database you’re going to use every single day at work. If you find yourself doing this, try to learn to consider it a sign that something has gone wrong.<br />
<a href="#87">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.088.jpeg" />
</td>