-
Notifications
You must be signed in to change notification settings - Fork 3
/
hacknot.html
14433 lines (13021 loc) · 669 KB
/
hacknot.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
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<!-- 2015-11-24 K 09:56 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Hacknot</title>
<meta name="generator" content="Org-mode" />
<meta name="author" content="Ed Johnson" />
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
.title { text-align: center;
margin-bottom: .2em; }
.subtitle { text-align: center;
font-size: medium;
font-weight: bold;
margin-top:0; }
.todo { font-family: monospace; color: red; }
.done { font-family: monospace; color: green; }
.priority { font-family: monospace; color: orange; }
.tag { background-color: #eee; font-family: monospace;
padding: 2px; font-size: 80%; font-weight: normal; }
.timestamp { color: #bebebe; }
.timestamp-kwd { color: #5f9ea0; }
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
pre {
border: 1px solid #ccc;
box-shadow: 3px 3px 3px #eee;
padding: 8pt;
font-family: monospace;
overflow: auto;
margin: 1.2em;
}
pre.src {
position: relative;
overflow: visible;
padding-top: 1.2em;
}
pre.src:before {
display: none;
position: absolute;
background-color: white;
top: -10px;
right: 10px;
padding: 3px;
border: 1px solid black;
}
pre.src:hover:before { display: inline;}
pre.src-sh:before { content: 'sh'; }
pre.src-bash:before { content: 'sh'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-R:before { content: 'R'; }
pre.src-perl:before { content: 'Perl'; }
pre.src-java:before { content: 'Java'; }
pre.src-sql:before { content: 'SQL'; }
table { border-collapse:collapse; }
caption.t-above { caption-side: top; }
caption.t-bottom { caption-side: bottom; }
td, th { vertical-align:top; }
th.org-right { text-align: center; }
th.org-left { text-align: center; }
th.org-center { text-align: center; }
td.org-right { text-align: right; }
td.org-left { text-align: left; }
td.org-center { text-align: center; }
dt { font-weight: bold; }
.footpara { display: inline; }
.footdef { margin-bottom: 1em; }
.figure { padding: 1em; }
.figure p { text-align: center; }
.inlinetask {
padding: 10px;
border: 2px solid gray;
margin: 10px;
background: #ffffcc;
}
#org-div-home-and-up
{ text-align: right; font-size: 70%; white-space: nowrap; }
textarea { overflow-x: auto; }
.linenr { font-size: smaller }
.code-highlighted { background-color: #ffff00; }
.org-info-js_info-navigation { border-style: none; }
#org-info-js_console-label
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
.org-info-js_search-highlight
{ background-color: #ffff00; color: #000000; font-weight: bold; }
/*]]>*/-->
</style>
<link rel="stylesheet" type="text/css" href="http://www.star.bris.ac.uk/bjm/css/bjm.css" />
<script type="text/javascript">
/*
@licstart The following is the entire license notice for the
JavaScript code in this tag.
Copyright (C) 2012-2013 Free Software Foundation, Inc.
The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
@licend The above is the entire license notice
for the JavaScript code in this tag.
*/
<!--/*--><![CDATA[/*><!--*/
function CodeHighlightOn(elem, id)
{
var target = document.getElementById(id);
if(null != target) {
elem.cacheClassElem = elem.className;
elem.cacheClassTarget = target.className;
target.className = "code-highlighted";
elem.className = "code-highlighted";
}
}
function CodeHighlightOff(elem, id)
{
var target = document.getElementById(id);
if(elem.cacheClassElem)
elem.className = elem.cacheClassElem;
if(elem.cacheClassTarget)
target.className = elem.cacheClassTarget;
}
/*]]>*///-->
</script>
</head>
<body>
<div id="content">
<h1 class="title">Hacknot
<br>
<span class="subtitle">Essays on Software Development</span>
</h1>
<div id="table-of-contents">
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#orgheadline423">1. Hacknot</a>
<ul>
<li><a href="#orgheadline3">1.1. Foreword</a>
<ul>
<li><a href="#orgheadline1">1.1.1. The Hacknot Web Site</a></li>
<li><a href="#orgheadline2">1.1.2. The Hacknot Book</a></li>
</ul>
</li>
<li><a href="#orgheadline135">1.2. Peopleware</a>
<ul>
<li><a href="#orgheadline30">1.2.1. The A to Z of Programmer Predilections </a></li>
<li><a href="#orgheadline31">1.2.2. The Hazards of Being Quality Guy </a></li>
<li><a href="#orgheadline51">1.2.3. A Dozen Ways to Sustain Irrational Technology Decisions </a></li>
<li><a href="#orgheadline57">1.2.4. My Kingdom for a Door </a></li>
<li><a href="#orgheadline72">1.2.5. Interview with the Sociopath </a></li>
<li><a href="#orgheadline89">1.2.6. The Art of Flame War </a></li>
<li><a href="#orgheadline102">1.2.7. Testers: Are They Vegetable or Mineral?* </a></li>
<li><a href="#orgheadline124">1.2.8. Corporate Pimps: Dealing With Technical Recruiters </a></li>
<li><a href="#orgheadline134">1.2.9. Developers are from Mars, Programmers are from Venus </a></li>
</ul>
</li>
<li><a href="#orgheadline188">1.3. Management</a>
<ul>
<li><a href="#orgheadline142">1.3.1. To The Management </a></li>
<li><a href="#orgheadline162">1.3.2. Great Mistakes in Technical Leadership </a></li>
<li><a href="#orgheadline164">1.3.3. The Architecture Group </a></li>
<li><a href="#orgheadline177">1.3.4. The Mismeasure of Man </a></li>
<li><a href="#orgheadline187">1.3.5. Meeting Driven Development </a></li>
</ul>
</li>
<li><a href="#EXAM">1.4. Extreme Programming and Agile Methods</a>
<ul>
<li><a href="#orgheadline196">1.4.1. Extreme Deprogramming </a></li>
<li><a href="#orgheadline203">1.4.2. New Methodologies or New Age Methodologies? </a></li>
<li><a href="#orgheadline209">1.4.3. Rhetorical AntiPatterns in XP </a></li>
<li><a href="#orgheadline214">1.4.4. The Deflowering of a Pair Programming Virgin </a></li>
<li><a href="#orgheadline218">1.4.5. XP and ESP: The Truth is Out There! </a></li>
<li><a href="#orgheadline221">1.4.6. Thought Leaders and Thought Followers </a></li>
</ul>
</li>
<li><a href="#orgheadline230">1.5. Requirements</a>
<ul>
<li><a href="#orgheadline226">1.5.1. Dude, Where's my Spacecraft? </a></li>
<li><a href="#orgheadline229">1.5.2. User is a Four Letter Word </a></li>
</ul>
</li>
<li><a href="#orgheadline247">1.6. Design</a>
<ul>
<li><a href="#orgheadline235">1.6.1. The Folly of Emergent Design </a></li>
<li><a href="#orgheadline246">1.6.2. The Top Ten Elements of Good Software Design </a></li>
</ul>
</li>
<li><a href="#orgheadline255">1.7. Documentation</a>
<ul>
<li><a href="#orgheadline248">1.7.1. Oral Documentation: Not Worth the Paper it's Written On </a></li>
<li><a href="#orgheadline254">1.7.2. FUDD: Fear, Uncertainty, Doubt and Design Documentation </a></li>
</ul>
</li>
<li><a href="#orgheadline277">1.8. Programming</a>
<ul>
<li><a href="#orgheadline262">1.8.1. Get Your Filthy Tags Out of My Javadoc, Eugene </a></li>
<li><a href="#orgheadline272">1.8.2. Naming Classes: Do it Once and Do it Right </a></li>
<li><a href="#orgheadline276">1.8.3. In Praise of Code Reviews </a></li>
</ul>
</li>
<li><a href="#orgheadline300">1.9. User Interfaces</a>
<ul>
<li><a href="#orgheadline286">1.9.1. Web Accessibility for the Apathetic[ </a></li>
<li><a href="#orgheadline299">1.9.2. SWT: So What?[ </a></li>
</ul>
</li>
<li><a href="#orgheadline344">1.10. Debugging and Maintenance</a>
<ul>
<li><a href="#orgheadline335">1.10.1. Debugging 101 </a></li>
<li><a href="#orgheadline336">1.10.2. Spare a Thought for the Next Guy </a></li>
<li><a href="#orgheadline343">1.10.3. Six Legacy Code AntiPatterns </a></li>
</ul>
</li>
<li><a href="#orgheadline404">1.11. Skepticism</a>
<ul>
<li><a href="#orgheadline359">1.11.1. The Skeptical Software Development Manifesto </a></li>
<li><a href="#orgheadline364">1.11.2. Basic Critical Thinking for Software Developers </a></li>
<li><a href="#orgheadline378">1.11.3. Anecdotal Evidence and Other Fairy Tales </a></li>
<li><a href="#fpnfsd">1.11.4. Function Points: Numerology for Software Developers </a></li>
<li><a href="#orgheadline400">1.11.5. Programming and the Scientific Method </a></li>
<li><a href="#orgheadline403">1.11.6. From Tulip Mania to Dot Com Mania </a></li>
</ul>
</li>
<li><a href="#orgheadline422">1.12. The Industry</a>
<ul>
<li><a href="#orgheadline408">1.12.1. The Crooked Timber of Software Development </a></li>
<li><a href="#orgheadline410">1.12.2. From James Dean to J2EE: The Genesis of Cool </a></li>
<li><a href="#orgheadline415">1.12.3. IEEE Software Endorses Plagiarism </a></li>
<li><a href="#orgheadline416">1.12.4. Early Adopters or Trend Surfers? </a></li>
<li><a href="#orgheadline417">1.12.5. Reuse is Dead. Long Live Reuse. </a></li>
<li><a href="#orgheadline421">1.12.6. All Aboard the Gravy Train </a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
</div>
<div id="outline-container-orgheadline423" class="outline-2">
<h2 id="orgheadline423"><span class="section-number-2">1</span> Hacknot</h2>
<div class="outline-text-2" id="text-1">
<p>
ASIN: B002EVD14U This work is licensed under the Creative Commons
Attribution License. To view a copy of this license:
</p>
<ul class="org-ul">
<li>Visit <a href="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</a> or</li>
<li>Send a letter to: Creative Commons, 543 Howard Street, 5th Floor, San
Francisco, California, 94105, USA</li>
</ul>
</div>
<div id="outline-container-orgheadline3" class="outline-3">
<h3 id="orgheadline3"><span class="section-number-3">1.1</span> Foreword</h3>
<div class="outline-text-3" id="text-1-1">
</div><div id="outline-container-orgheadline1" class="outline-4">
<h4 id="orgheadline1"><span class="section-number-4">1.1.1</span> The Hacknot Web Site</h4>
<div class="outline-text-4" id="text-1-1-1">
<p>
Hacknot began life in 2001 as an internal mailing list at the
multinational telecommunications company I was then working for. As part
of the activities of the local Software Engineering Process Group, I was
looking for a way to promote discussion amongst staff about software
engineering related issues, and hopefully encourage people to learn
about the methods and techniques that could be used to improve the
quality of their work. A creative colleague came up with the name
“Hacknot” for the mailing list … a pun on the geek web site
“slashdot.”
</p>
<p>
A few years later, when I left the company, I restarted Hacknot as an
externally hosted mailing list, with many of the same members as in its
last incarnation. In 2003, I was looking for a coding exercise in J2EE,
the main technologies of which had passed me by while I was busy working
in other areas. Growing tired of building play-applications like bug
trackers and online store simulations, I decided to create a web version
of the Hacknot mailing list. I figured it would give me a “real world”
context in which to learn about J2EE, and also a project that I could
pursue without the interference of the usually inept management that so
plagued the development efforts of my working life.
</p>
<p>
So in 2003 the Hacknot web site was born. In Australia, domain name
registration rules restrict ownership of “.com” domains to commercial
enterprises, so I chose the next best top-level domain, which was
“.info”.
</p>
<p>
Initially, I imagined that the web site would host works by a variety of
authors, myself included. But when it came time to put pen to paper,
almost all of those who had previously expressed interest in
participating suddenly backed off, leaving me to write all the content
myself.
</p>
<p>
Many of the essays on Hacknot take a stab at some sacred cow of the
software development field, such as Extreme Programming, Open Source and
Function Point Analysis. These subjects tend to attract fanatical
adherents who don't take kindly to someone criticizing what for them has
become an object of veneration. The vitriol of some of the e-mail I
receive is testament to the fact that some people need to get out more
and get a sense of perspective. It is partially because of the
controversial nature of these topics that I have always written behind a
pseudonym; either “Ed” or “Mr. Ed”. I also favor anonymity because it
makes a nice change from the relentless self-promotion engaged in by so
many members of the IT community.
</p>
</div>
</div>
<div id="outline-container-orgheadline2" class="outline-4">
<h4 id="orgheadline2"><span class="section-number-4">1.1.2</span> The Hacknot Book</h4>
<div class="outline-text-4" id="text-1-1-2">
<p>
This book contains 46 essays originally published on the Hacknot web
site between 2003 and 2006. The version of each essay appearing in the
book is substantially the same as the online version, with some minor
revisions and editing.
</p>
<p>
You can freely download PDFs of this book with page sizes of 6” x 9” or
A4, by visiting <a href="http://www.hacknot.info/">http://www.hacknot.info/</a>. There you will also find
instructions on how you can obtain a hard-cover copy, for the price of
the binding and postage. Please send any comments or corrections to
editor@hacknot.info.
</p>
</div>
</div>
</div>
<div id="outline-container-orgheadline135" class="outline-3">
<h3 id="orgheadline135"><span class="section-number-3">1.2</span> Peopleware</h3>
<div class="outline-text-3" id="text-1-2">
</div><div id="outline-container-orgheadline30" class="outline-4">
<h4 id="orgheadline30"><span class="section-number-4">1.2.1</span> The A to Z of Programmer Predilections <sup><a id="fnr.1" class="footref" href="#fn.1">1</a></sup></h4>
<div class="outline-text-4" id="text-1-2-1">
<p>
There is a realization that comes with the accrual of software
development experience across a reasonable number of organizations, and
it is this:
</p>
<blockquote>
<p>
<i>Though the names change, the problems remain the same.</i>
</p>
</blockquote>
<p>
Traveling from project to project, from one organization to another,
across disparate geographies, domains and technologies, I am repeatedly
struck more by the similarities between the projects I work on than
their differences. Scenes from one job seem to replay in the next one,
only with a different set of actors.
</p>
<p>
You might finish a gig in which you've seen a project flop due to
inadequate consultation with end users, only to find your next project
heading down the same path for exactly the same reason. And it generally
doesn't matter how much you jump up and down and try and warn your new
project team that you've seen the disastrous results of similar actions
in the past. They will ignore you, insisting that their situation is
somehow different. You will stand back and watch in horror as the whole
scenario plays out as you knew it would, all the while unable to do
anything more to prevent it. The IT contractor's career can be like some
cruel matinee of "Groundhog Day" – without the moral resolution at the
end.
</p>
<p>
But this technological déjà vu is not limited to technical scenarios -
it extends to people. I find myself working with the same programmers
over and over again. Their names and faces change, but their
personalities and predilections are immediately recognizable. I find
myself playing mental games of "Snap" with my fellow developers. "Bob
over there is just like Ian from Acme. James is this workplace's
equivalent of Charles from that financial services gig I had last year"
– and so on.
</p>
<p>
Sometimes I fancy that I have met them all. There will be no new
developers for me to work with in future – only the reanimated ghosts
of projects past. The same quirks and foibles that I've endured in the
past will haunt me the rest of my days.
</p>
<p>
I've listed below the cast of characters that have been following me
around for some years now. Coincidentally, there are exactly twenty six
of them, one for each letter of the alphabet. Perhaps you've encountered
some of them yourself. Perhaps you're one of them. If so – please go
away and find someone else to bug.
</p>
</div>
<ol class="org-ol"><li><a id="orgheadline4"></a>Arrogant Arthur<br /><div class="outline-text-5" id="text-1-2-1-1">
<p>
The three hardest words in any techie's vocabulary are "I don't know".
Arthur never has to struggle with them, for he knows everything. Any
technology you might name - he's an expert. Any problem you might have
– he's solved it before. No matter what challenge he's assigned – he's
sure it will be easy. Whenever Arthur appears to have made a mistake,
closer investigation will reveal that the fault in fact lies with
someone or something else. Arthur is a pretty handy conversationalist.
Whenever you're having a technical discussion with someone and he is
within earshot, Arthur will generally join in and quickly dominate the
discussion with his displays of erudition. Uncertainty and self-doubt
are states of mind that Arthur is entirely unfamiliar with. Arthur has a
tendency to make big generalizations and sweeping statements, as if to
imply that he has the certainty that only comes from vast experience.
</p>
</div></li>
<li><a id="orgheadline5"></a>Belligerent Brian<br /><div class="outline-text-5" id="text-1-2-1-2">
<p>
Nobody in the office is particularly fond of Brian. Sure, he's a smart
guy and seems to be technically well informed, but he has such a
strident and aggressive manner that it's difficult to talk with him for
any length of time without feeling that you are under attack. Brian
likes it that way and his hostile manner is entirely intentional. You
see, Brian is a go-getter. Highly ambitious and energetic, he is
determined to advance up the corporate ladder, no matter who he has to
step on in the process. Whenever any action is undertaken or decision
made, there is always a part of him thinking "How will this make me look
to my manager?" It's not surprising then that not all of Brian's
decisions are good ones. He has been known to select cutting edge
technologies simply for their buzzword compliance, betting that cool
acronyms and shiny new methodologies will make him appear progressive
and forward-looking. Although he regularly makes mistakes, Brian never
admits to any of them, and generally blames third parties, vendors and
colleagues for errors that are actually his own.
</p>
</div></li>
<li><a id="orgheadline6"></a><code>C++</code> Colin<br /><div class="outline-text-5" id="text-1-2-1-3">
<p>
Colin is the local language bigot, whose language of preference is C++.
He began programming in C, moved on to C++ when commercial forces threw
the OO paradigm at him, and has been working in C++ ever since. Colin
has watched the ascent of Java with a mixture of disdain and veiled
jealousy. Initially, it was easy to defend C++ against criticisms from
the Java camp, by pointing to C++'s superior performance. But with the
growing speed of JVMs, this advantage has been lost. Now, most of the
advantages that Colin claims for C++ are the same language features that
Java enthusiasts see as disadvantages. Java developers (or, "Java
weenies" as Colin is fond of calling them) point to automatic memory
reclamation as an eliminator of a whole category of bugs that C++
developers must still contend with. Colin sees garbage collection as
disempowering the programmer, referring to the random intrusion of
garbage collection cycles as payback for those too lazy to free memory
themselves. Java weenies consider the absence of multiple inheritance in
Java an advantage because it avoids any confusion over the rules used to
resolve inheritance of conflicting features; Colin sees it as an
unforgivable limitation to effective and accurate domain modeling. Java
weenies consider C++'s operator overloading to be an archaic syntax
shortcut, rife with potential for error; Colin sees it as a concise and
natural way to capture operations upon objects. Colin displays a certain
bitterness, resulting from the dwindling variety of work available to
him within the language domain he is comfortable with.
</p>
</div></li>
<li><a id="orgheadline7"></a>Distracted Daniel<br /><div class="outline-text-5" id="text-1-2-1-4">
<p>
Daniel's mind is only ever half on the job, or to put it another way, he
doesn't have his head in the game. Daniel lives a very full life –
indeed, so full that his private life overflows copiously into his
professional one. He has several hobbies that he is passionate about,
and he is always ready to regale a colleague with tales of his weekend
exploits in one of them. It looks as if his job is just a way of funding
his many (often expensive) hobbies. His work is strictly a nine to five
endeavor, and it would be very rare to find him reading around a
particular work-related topic in his own time, or putting in an
extraordinary effort to meet a deadline or project milestone. He is
constantly taking off at lunch times to take care of one task or
another, and does not seem to be particularly productive even when he is
in the office. Daniel refers to this as "leading a balanced life". He
may be right.
</p>
</div></li>
<li><a id="orgheadline8"></a>Essential Eric<br /><div class="outline-text-5" id="text-1-2-1-5">
<p>
Eric knows that knowledge is power. Partly by happenstance but mostly by
design, Eric has become irreplaceable to his employer. There just seems
to be a vast amount of technical and procedural arcana that only Eric
knows. If he should ever leave, the company would be in a mess, as he
would take so much critical information with him. This gives him a good
deal of bargaining power with management, and good job security. A few
of the company's managers have recognized the unhealthy dependence that
exists upon him, and have attempted to document some of the valuable
knowledge about certain pieces of software central to the business, but
Eric always finds a way to get out of it. There always seems to be
something more pressing for him to do, and if he is forced to put pen to
paper, what results tends to be incoherent nonsense. It seems that he
just can't write things down - or rather, that he chooses to be so poor
at it that no one even bothers to ask him to document things any more.
Eric is not keen to help others in those domains that he is master of,
as he doesn't want to dilute the power of his monopoly.
</p>
</div></li>
<li><a id="orgheadline9"></a>Feature Creep Frank<br /><div class="outline-text-5" id="text-1-2-1-6">
<p>
Most of the trouble that Frank has got himself into over the years has
been heralded by the phrase "Wouldn't if be cool if … ". No matter how
feature-laden his current project may be, Frank can always think of one
more bell or whistle to tack onto it that will make it so much cooler.
Having decided that a particular feature is critical to user acceptance
of the application, it is a very difficult task to stop him adding it
in. He has been known to work nights and weekends just to get his
favorite feature incorporated into the code base – whether he has got
permission to do so or not. Part of Frank's cavalier attitude to these
"enhancements" comes from his unwillingness to consider the long term
consequences of each addition. He tends to think of the work being over
once the feature has been coded, but he fails to consider that this
feature must now be tested, debugged and otherwise maintained in all
future versions of the product. Once the users have seen it, they may
grow accustomed to it, and so removing it from future versions may well
be impossible. They may even like the feature so much that they begin
requesting extensions and modifications to it, creating further burden
on the development team. Frank justifies his actions to others in terms
of providing value to users, and often professes a greater knowledge of
the user demographic than what he actually possesses, so that he can
claim how much the users will need a particular feature. But Frank's
real motivations are not really about user satisfaction, but are about
satisfying his own ego. Each new feature is an opportunity for him to
demonstrate how clever he is, and how in touch with the user community.
</p>
</div></li>
<li><a id="orgheadline10"></a>Generic George<br /><div class="outline-text-5" id="text-1-2-1-7">
<p>
George delights in the design process. Pathologically incapable of
solving just the immediate problem at hand, George always creates the
most generic, flexible and adaptable solution possible, paying for the
capabilities he thinks he will need in the future with extra complexity
now. Sadly, George always seems to anticipate incorrectly. The castles
in the air that he continually builds rarely end up with more than a
single room occupied. Meanwhile, everyone must cope with the inordinate
degree of time and effort that is needlessly invested in managing the
complexity of an implementation whose flexibility is never required. It
is a usual characteristic of George's work that it takes at least a
dozen classes working together to accomplish even trivial functionality.
He is generally the first to declare "Let's build a framework" whenever
the opportunity presents itself, and the last to want to use the
framework thus created.
</p>
</div></li>
<li><a id="orgheadline11"></a>Hacker Henry<br /><div class="outline-text-5" id="text-1-2-1-8">
<p>
Henry considers himself to be a true hacker – a code poet and geek
guru. Still in the early stages of his career, he spends most of his
life in front of a keyboard. Even when not at work, he is working on his
own projects, participating in online discussion forums and learning
about the latest languages and utilities. Software is his principal
passion in life. This single-minded pursuit of technical knowledge has
made him quite proficient in many areas, and has engendered a certain
arrogance that generally manifests as a disdain directed towards those
of his colleagues whom he regards as not being "true hackers". For his
managers, Henry is a bit of a problem. They know that they can rely on
him to overcome pretty much any technical challenge that might be
presented to him, provided that the solution can be reached by doing
nothing but coding. For unless it's coding, Henry's not interested. He
won't document anything; certainly not his code, because he feels that
good code is self-documenting. He is early enough into his career to
have not yet been presented with the task of adopting a large code base
from someone who subscribes to that same belief, and to have thereby
seen the problems with it. Also, Henry can generally only be given
"mind-size" tasks to do. His tasks have to be small and well defined
enough for him to fit all their details in his head at once, as he
simply refuses to write anything down. The architecture of
enterprise-scale systems will likely forever be a mystery to him as he
does not possess, and has no interest in developing, the facility with
abstractions and modeling that is necessary to manage the design of
large systems.
</p>
</div></li>
<li><a id="orgheadline12"></a>Incompetent Ian<br /><div class="outline-text-5" id="text-1-2-1-9">
<p>
Ian is a nice enough guy but is genuinely incapable of performing most
of the job functions his position requires. It's not clear whether this
is a result of inadequate education, limited experience or simply a lack
of native ability. Either way, it is clear to anyone who works with Ian
for any length of time that he is not really on the ball, and takes a
very long time to complete even basic tasks. Worst of all, Ian seems to
be blissfully unaware of his own incompetence. This can make for some
embarrassing situations for everyone, as Ian's attempts to weigh in on
technical discussions leave him looking naive and ignorant – which he
also fails to notice. Ian tends to get work based upon his personable
manner and the large number of friends he has working in the industry.
Most of his employers have come to view him as a "retrospective hiring
error".
</p>
</div></li>
<li><a id="orgheadline13"></a>Jailbird John<br /><div class="outline-text-5" id="text-1-2-1-10">
<p>
John has been working for his current employer a long time. A very long
time. Longer than most of the senior management in fact. John has been
working here so long that it is highly unlikely he will ever be able to
work anywhere else. Over the years, his skill set has deteriorated so
greatly and become so stale that he has become an entirely unmarketable
commodity. He knows all there is to know about the company's legacy
applications – after all, he wrote most of them. He has been keeping
himself employed for the last decade just patching them up and making
one piecemeal addition after another in order to try and keep them
abreast of the business's changing function. Tired of chasing the latest
and greatest technologies, he has not bothered learning new ones,
sticking to the comfortable territory defined by the small stable of
dodgy applications he has been shepherding for some years. John gets
along with everyone, particularly those more senior to him. He can't
afford the possibility of getting into conflict with anyone who might
influence his employment status, as he knows that this will likely be
the last good job he ever has. So he tries to stay under the radar,
hoping that the progressive re-engineering of his pet applications with
more modern technologies takes long enough for him to make it over the
finish line.
</p>
</div></li>
<li><a id="orgheadline14"></a>Kludgy Kevin<br /><div class="outline-text-5" id="text-1-2-1-11">
<p>
Kevin is remarkably quick to fix bugs. It seems that he's no sooner
started on a bug fix than he's checking in the solution. And then, as if
by magic, the very same bug reappears. "I thought I fixed that",
declares Kevin – and indeed he did – but not properly. In his rush to
move on to something else, Kevin invariably forgets to check that his
"fix" works correctly under some boundary condition or special case, and
ends up having to go back and fix it again. Sometimes a third or even
fourth attempt will be necessary. This is Kevin's version of "iterative
development."
</p>
</div></li>
<li><a id="orgheadline15"></a>Loudmouth Lincoln<br /><div class="outline-text-5" id="text-1-2-1-12">
<p>
Terror of the cubicle farm, Lincoln incurs the ire of all those who sit
anywhere near him, but remains blissfully unaware that he is so
unpopular. His voice is louder than anyone else's by a least a factor of
two, and he seems unable to converse at any volume other than full
volume. When Lincoln is talking, everyone else is listening, whether
they want to or not. People in his part of the office know a great deal
more about Lincoln's personal life than they would like, as they have
heard one end of the half dozen or so telephone calls that he seems to
receive from his wife every day. Lincoln's favorite instrument of
torture is the speakerphone. He always listens to his voicemail on
speakerphone each morning, so that he can unpack his briefcase while
doing so. He also likes to place calls on speakerphone so that his hands
are free to type at his keyboard while conversing with someone else. He
either doesn't realize or doesn't care that he is disturbing those
nearby. Nobody seems to be game enough to tell him how inconsiderate he
is being.
</p>
</div></li>
<li><a id="orgheadline16"></a>Martyr Morris<br /><div class="outline-text-5" id="text-1-2-1-13">
<p>
Morris is very conscious of the impression others form of him. Probably
a little too concerned. He has observed that many of his colleagues
associate long hours with hard work and dedication. The longer the
hours, the harder you're working – and having a reputation as a hard
worker can only be a good thing when it comes performance review time.
So Morris makes sure he is at the office when his boss arrives of a
morning, and that he is still working away when his boss leaves of an
afternoon. Everyone agrees that Morris certainly puts in the hard yards,
but are a little perplexed as to why his code is so often buggy and
poorly structured. In fact, it seems like Morris has to put in extended
hours in order to compensate for the poor quality of his work. The net
result is that he gets almost as much achieved as his team mates who
work more sensible hours. Morris hasn't yet twigged to the fact that his
defect injection rate rises dramatically as he fatigues, meaning that
the extra hours he works often have a negative effect on his
productivity. Worse yet, his know-nothing manager rewards him for his
dedication, thereby reinforcing the faulty behavior.
</p>
</div></li>
<li><a id="orgheadline17"></a>Not-Invented-Here Nick<br /><div class="outline-text-5" id="text-1-2-1-14">
<p>
Nick has an overwhelming drive to write everything himself. Due to
hubris and ambition, he is rarely satisfied with buying a third party
utility or library to help in his development efforts. It seems to him
that the rest of the industry must be incompetent, for every time he
looks to buy rather than build, he finds so many shortcomings in the
products on offer that he invariably concludes that there's nothing for
it but to write the whole thing himself. It also seems that his
particular requirements are always so unique that no generally available
tool has just the functionality that he needs. Not wanting to work
inefficiently, he insists on only using tools that do exactly what he
wants – nothing more, nothing less. Little wonder then that he finds
himself having to write such fundamental utilities as text editors, file
transfer programs, string and math utility libraries. The real problem
is not that Nick's requirements are so unique, but that he deliberately
fabricates requirements so specific that he can find commercial
offerings lacking, and thereby justify reinvention of those offerings
himself. In short, he is looking for excuses to write what he considers
to be the "fun stuff" (the development tools) rather than the "boring
stuff" (the application code). He generally has little difficulty in
finding such justifications. Most people who work with Nick note with
interest that the tools that he writes himself are rarely of the quality
of the equivalent commercial offerings.
</p>
</div></li>
<li><a id="orgheadline18"></a>Open Source Oliver<br /><div class="outline-text-5" id="text-1-2-1-15">
<p>
Oliver is very enthusiastic about open source software development. He
contributes to several open source projects himself, and tries to
incorporate open source products into his projects wherever possible –
and it's always possible; mainly because Oliver begins a project for the
principal purpose of providing himself with an opportunity to try out
the latest and greatest CVS build from Apache, Jakarta or wherever.
Oliver rarely has to justify his technology selections to his
colleagues, as he is always sure to surround himself with other open
source believers. On occasions when he needs to explain the failure or
buggy nature of some open source package, he relies upon the old saw "we
can always fix it ourselves". However there never seems to be enough
time in the schedule for this to actually occur; so every release of his
project bristles with the underlying warts of its open source
components. If all else fails, it can at least be said that the price is
right.
</p>
</div></li>
<li><a id="orgheadline19"></a>Process Peter<br /><div class="outline-text-5" id="text-1-2-1-16">
<p>
If you want to see Peter get worked up, just start a discussion with him
about the poor state of software development today. He will hold forth
at length, and with passion, on where it has all go wrong. And Peter has
decided that all of software's woes have a common genesis – a lack of
disciplined process. Peter's career history reads like a marketing
brochure of process trends. BPR, Clean Room, Six Sigma, ISO – he's been
a whole-hearted enthusiast of them all at one time or another. His
dedication to strict process adherence as a panacea to a project's
quality ills is absolute, and he will do almost anything to ensure that
ticks appear in the relevant boxes. Unfortunately, this uncompromising
approach is often self-defeating, as it denies him the flexibility to
adapt quality levels on a case-by-case basis. It has also made him more
than a few enemies over the years. He is prone to considering the people
component of software development as a largely secondary consideration,
and views programmers a little like assembly line production workers –
interchangeable parts whose individual talents and proclivities are not
so important as the procedures they follow to do their work. Those
subject to such views tend to find it more than a little dehumanizing
and impersonal.
</p>
</div></li>
<li><a id="orgheadline20"></a>Quiet Quincy<br /><div class="outline-text-5" id="text-1-2-1-17">
<p>
Quincy is one of those guys who has no need to brag about his technical
skills or the depth of his technical knowledge. He's not much interested
in being "alpha geek" at the office, he just wants to do a good job and
then go home to his wife and children. Quietly spoken and unassuming, he
looks on with amusement at Zealous Zack's ever-changing enthusiasms and
shakes his head, knowing that in a few more years Zack will have gained
enough experience to know that the computing industry is full of "next
big things" that generally aren't. Given a task, he just sits down and
does it. He doesn't succumb to heroic bug-fixing and late night coding
efforts – his code is good enough to begin with that won't get many
pats on the back from management, whose attention will largely be
captured by the technical prima donnas that swan around the project
space, dropping buzzwords and acronyms like they were the names of
celebrities they knew personally. But without Quincy and those of his
ilk, the project would fail – because someone has to get the work done.
</p>
</div></li>
<li><a id="orgheadline21"></a>Rank Rodger<br /><div class="outline-text-5" id="text-1-2-1-18">
<p>
Rodger is very good at what he does. He's a techie through and through,
and delights in problem solving. The problem is that Rodger lives in his
head. At times he feels like a brain on legs, so focused is he upon
intellectual pursuits. His body is a much neglected container for
cortical function that he generally pays little attention to, except to
meet its basic functional requirements for food and clothing. As a
result, there is a certain funk surrounding Rodger which nearby
colleagues are all too aware of, but of which Rodger is olfactorily
ignorant. Halitosis is his constant companion and dandruff a regular
visitor. In general, he has unkempt appearance – his shirt often
buttoned incorrectly, hair not combed and tie (which he wears only under
the greatest duress) knotted irregularly. Rodger doesn't really care
what others think of him and is largely unaware of the message his poor
grooming and hygiene is sending to others. Rodger is likely to remain
unaware for a long time, as nobody can think of a way of broaching the
topic with him that wouldn't cause offense.
</p>
</div></li>
<li><a id="orgheadline22"></a>Skill Set Sam<br /><div class="outline-text-5" id="text-1-2-1-19">
<p>
Sam is just passing through. If he is a contractor, everyone will
already be aware of this. If he is permanent staff, his colleagues might
be a little surprised to know just how certain he is that he won't be
working here in a year's time. Sam is committed to accumulating as much
experience with as many technologies as he possibly can, in order to
make himself more attractive to future employers. His career objective
is simply that he remain continually employed, earning progressively
higher salaries until he is ready to retire.
</p>
</div></li>
<li><a id="orgheadline23"></a>Toolsmith Trevor<br /><div class="outline-text-5" id="text-1-2-1-20">
<p>
Trevor loves to build development tools. He can whip you up a build
script in a few minutes and automate just about any development task you
might mention. In fact, Trevor can't be stopped from doing these things.
He is actively looking for things to automate – whether they need it or
not. For some reason, Trevor doesn't see the writing of development
tools as a means to an end, but an end in itself. The living embodiment
of the "Do It Yourself" ethic, Trev insists on writing common
development tools himself, even if an off-the-shelf solution is readily
available. Rather than chose one of the million commercially available
bug tracking applications, you can rely on Trevor to come up with an
argument as to why none of them are adequate for your purposes, and
there is no solution but for him to write one. At the very least, he
will have to take an open source tool and customize it extensively. So
too with version management, document templates and editor configuration
files. Trevor is right into metawork, with the emphasis on the meta.
</p>
</div></li>
<li><a id="orgheadline24"></a>Unintelligible Uri<br /><div class="outline-text-5" id="text-1-2-1-21">
<p>
English is not Uri's native tongue. This is blatantly obvious to anyone
who attempts to communicate with him. He speaks with a thick accent and
at such a rapid pace that listeners can go several minutes in
conversation with him without having a clear idea of what he has said.
Trying to work with Uri can be an excruciating experience. He cannot
contribute to technical discussions effectively, regardless of how well
informed he might be, because he is always shouted down by those with
more rhetorical flair, regardless how uninformed they might be.
Delegating work to him is a dangerous undertaking because you can never
be certain that he has really understood the description of his
assignment; he tends to respond with affirmative clichés that can be
easily said, but don't necessarily reflect that information has been
successfully communicated. Very often, people choose simply not to
bother communicating with Uri, because they find it both exhausting and
frustrating. Whoever hired Uri has failed to appreciate that fluency in
a natural language is worth ten times as much as fluency in a
programming language.
</p>
</div></li>
<li><a id="orgheadline25"></a>Vb Victor<br /><div class="outline-text-5" id="text-1-2-1-22">
<p>
Sometime in the nineties Victor underwent what is colloquially referred
to as a "Visual Basic Lobotomy". He found himself a programmer on a
misconceived and overly ambitious VB project, and fought to write a
serious enterprise application for some years in a language that was
never conceived for more than small scale usage. Visual Basic Land is a
warm and soothing place, and Victor let his skill set atrophy while he
slaved away at VB, until eventually VB was all he was good for. Now,
dispirited and deskilled, he is a testament to the hazards of building
your career upon a narrow technological basis. Victor will likely
survive a few more years, pottering from one VB project to the next,
until he loses the enthusiasm even for that.
</p>
</div></li>
<li><a id="orgheadline26"></a>Word Salad Warren<br /><div class="outline-text-5" id="text-1-2-1-23">
<p>
Unlike Uri, Warren's native tongue is English; but it does him little
good. Listening to Warren explain something technical is like listening
to Dr Seuss – all the words make sense when taken individually, but
assembled together they seem to be mostly gibberish with no coherent
message. Such is Warren's talent for obfuscation, he can take simple
concepts and make them sound complex; take complex topics and make them
sound entirely incomprehensible. This is big problem for everyone
attempting to collaborate with Warren, for they generally find it
impossible to understand the approach Warren is taking in solving his
part of the problem, which virtually guarantees it won't work properly
in conjunction with other's work. On those rare occasions when he tries
to document his code, the comments aren't useful, as they make no more
sense than Warren would if he were explaining the code verbally.
Management has made the mistake of assuming that Warren's diatribes are
inscrutable because he is so technically advanced and is describing
something that is inherently complex. That's why he is in a senior
technical position. But his pathetic communication skills are a major
impediment to the duties he must perform as a senior developer, which
routinely involve directing and coordinating the technical work of
others by giving instructions and feedback. Warren is a source of great
frustration to his colleagues, who would give anything for precise and
concise communication.
</p>
</div></li>
<li><a id="orgheadline27"></a>X-Files Xavier<br /><div class="outline-text-5" id="text-1-2-1-24">
<p>
Xavier takes a little getting used to. Although his programming skills
are decidedly mature, his personality seems to be lagging behind. He has
an unhealthy fascination with Star Trek, Dr Who and Babylon 5. Graphic
novels and Dungeons and Dragons rule books are littered about his
cubicle, and he can often be found reading them during his lunch break,
which he always spends in front of his computer, surfing various science
fiction fan sites and overseas toy stores. Project meetings involving
Xavier are generally … interesting, but somewhat tiring. He regularly
interjects quotations from Star Wars movies and episodes of Red Dwarf,
laughing in an irritating way at his own humor, oblivious to the fact
that others without his rich fantasy life are not amused by his obscure
pop culture references. Xavier seems to spend most of his time by
himself. No one has ever heard him mention a girl-friend. Those who have
worked with him for any length of time know that he is best kept away
from customers and other "normal people" who would not understand his
eccentricities.
</p>
</div></li>
<li><a id="orgheadline28"></a>Young Yasmin<br /><div class="outline-text-5" id="text-1-2-1-25">
<p>
Yasmin has only been out of University for a few years. She is
constantly surprised by the discrepancy between what she was taught in
lectures and what actually appears to happen in industry. In fact, there
seems to be a good deal that happens in practice that was not
anticipated at all by her tertiary education. She concludes that the
numerous shortcuts, reactive management and run-away bug count of her
projects are just localized eccentricities, rather than a widespread
phenomenon. Yasmin fits well into the startup company environment, with
its prevailing attitude of "total dedication." Indeed, she is the target
employee demographic of such firms. She is at that stage of life where
she has the stamina to work 60 and 70 hour weeks on a regular basis. She
is not distracted by family commitments, and is ambitious and eager
enough to still be willing to do what is necessary to impress others.
Lacking industry experience and the perspective that comes with
maturity, she is not assertive enough to stand up to management when
they make excessive demands of her.
</p>
</div></li>
<li><a id="orgheadline29"></a>Zealous Zack<br /><div class="outline-text-5" id="text-1-2-1-26">
<p>
Zack is a very enthusiastic guy. In fact, there seems to be very little
going on in the world of computing that Zack is not enthusiastic about.
Like a kid staring in the candy store window, Zack gazes longingly at
every new buzzword, acronym and advertising campaign that crosses his
path, immediately becoming a disciple of every new movement and
technology craze that comes along. Sometimes these enthusiasms bring
with them certain ideological conflicts, but Zack is too busy
downloading the Beta version of the next big thing to be worried about
such matters. He runs Linux on his home PC, has a Mac Mini in his living
room, and worships at the church of Agile. Having Zack on your project
can be challenging, particularly if he exercises any control over
technology selection. He will invariably try and load down your project
with whatever "cool" technologies he is presently over-enthused about,
and delight in the interoperability problems that result as an
opportunity to introduce even more technologies to save the day. Zack
never quite learnt to distinguish work from play.
</p>
</div></li></ol>
</div>
<div id="outline-container-orgheadline31" class="outline-4">
<h4 id="orgheadline31"><span class="section-number-4">1.2.2</span> The Hazards of Being Quality Guy <sup><a id="fnr.2" class="footref" href="#fn.2">2</a></sup></h4>
<div class="outline-text-4" id="text-1-2-2">
<p>
Perhaps you've seen the Dilbert comic about Process Girl. At a meeting,
the Pointy Haired Boss introduces Process Girl as "the one who has the
answer to everything", at which point Process Girl chimes in parrot-like
with "Process!" She then denounces the meeting as inefficient because
the participants have no process to describe how to conduct a meeting.
By a unanimous vote she is expelled from the meeting. As he escorts her
out of the room, Dilbert offers by way of consolation "at least you
lasted longer than Quality Guy."
</p>
<p>
And now I must reveal a shocking truth … ladies and gentlemen (rips
open shirt to reveal spandex body suit with "Q" emblazoned on the front)
… I am Quality Guy. I am that much maligned coworker that you love to