此篇為 but 翻譯的文章，很久以前看過，剛又看到一次。由於新 blog 網址我真的連不上，所以只好先連舊的。此文有理至極，推薦給每個軟體界的程式設計師、PM、SE、業務、客戶。
引文如下：
(版本2 2008/10/12更新)
譯註
SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
程式設計師多半自己不面對客戶。
跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）
—————
1
每天有24小時。
所謂的「今天之內」，是指到明天早上為止。
2
程式不會照自己所想的跑。只會照所寫的跑。
3
需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4
我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
5
程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！
6
畫面藍了。
7
先說「沒辦法」的人贏。
8
有意見的話你寫
9
要殺一個程式設計師不需要刀，改三次規格就好
10
首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
11
開發沒有終點。只有釋出(release)。
12
無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
13
客戶總是覺得水跟追加需求是不用錢的。
14
付錢愈計較的客人愈囉唆。
15
在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
16
一個人掛了大家都掛了。
17
bug過了一晚可能就變成規格了。
18
好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
19
客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。
20
對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。
21
顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
22
很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。
23
品質的劣化程度依規格改變的次數與規模而定。
24
業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
25
有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
26
程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
27
程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
28
對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
29
程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。
30
SE需要持久力，程式設計師需要爆發力。
31
準時離開公司，工作會變多。
32
完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
33
詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
34
還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
35
程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
36
所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…
37
地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
38
遠處的火災一定燒到這裡。
39
禱告，然後跑吧。
40
程式不是用腦記的，要用身體記住。
41
明天能放假的話死了也罷。
42
外面有下雨耶，昨天開始下的嗎？
43
若不能心靜不移，身體會掛。
若不讓自己殘忍，自己會被殺。
44
客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）
45
（日文文字遊戲）
SE總是不負責的說「別逞強」，
業務總是無理取鬧不准說「沒辦法」。
46
規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
47
再嘮嘮叨叨下去也是要付錢的。
48
多想個10秒鐘，你可以不說「嗯，這個做得到」。
49
人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。
50
老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。
51
所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
52
程式、SE、經理不是職務。是逃不掉的責任。
53
業務是最難搞的客戶。
54
能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley
55
漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…
56
上線後的除錯才叫做bug。
57
追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。
58
除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
59
不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。
60
要解決地獄的辦法，就是客戶把錢交出來。
61
不懂電腦的操作者是發現bug的天才。而且無法重現。
62
每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。
63
搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）
64
啊，那是微軟的規格。
65
程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）
66
程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
67
正因為健康，才能做不健康的事。
68
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
69
那是你說的規格。
70
開發室沒有窗戶，那是因為以前…
71
爛了也是因為規格。
72
SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）
73
為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。
74
不會動的bug就只是普通的bug。（會動的bug則能視為規格）
75
今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。
76
客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。
77
唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。
78
共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。
79
如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
80
對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫租這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。
81
設計者應該是不該要求製作者製作出超過設計以上內容的吧…
82
無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。
83
SE對程式設計師說的「常識」每三小時變一次。
84
自己看規格書。不能跑的是規格。
85
「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。
86
工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。
87
能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。
88
累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）
89
試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。
90
REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
（譯註：我比較煩惱 Linux）
91
有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
92
小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路
93
「不要讓老闆當業務比較好」
94
說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。
————————
ex 1
就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。
ex 2
規格與規格書是不同的東西。
ex 3
比期限更重要的是靈感與睡眠。
ex 4
比知識與經驗重要的是手冊與時間。
ex 5
能動就好了，能動的話…
ex 6
過了三天就是別人寫的程式碼。
ex 7 (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！
ex 8 (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！
ex 9
漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了
ex 10
bug與規格是一體兩面
ex 11
電腦裡沒有bug，bug常在人心。
ex 12
無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)
ex 13
估價需要1%的經驗與99%的直覺
ex 14
沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
ex 15
・『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
・『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
・『PM』＝每天修改自己定下的行程表的人
・『業界老鳥』＝臉色蒼白缺乏表情的人
・『外包』＝幫不會寫程式的正職員工寫程式的人
・『coding』＝複製貼上的工作
・『單體測試』＝指開始寫程式
・『除錯』＝把程式碼註解掉的工作
・『新同事』＝在火燒屁股的專案火上加油的人
・『出貨日』＝把只完成一半的系統上線的日子
・『末班電車』＝業界平均的下班時間
・『颱風假』＝一年一度可以準時下班的業界假日
ex 16
當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
ex 17
最終手段
「重開機」
意外的常常都很有效
ex 18
最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
ex 19
「程式碼的可信度，不會比寫的人還可信。」
2009/3/25 補上日文版及出處：
プログラマーの格言（盗作多し）
一日は24時間ある。
今日中という意味は明日の朝までという意味である。
プログラマーの格言2（盗作多し）
プログラムは思った通りに動かない。書いた通りに動く。
プログラマーの格言3（盗作多し）
要求仕様はプログラム完成後に完結する。
基本仕様は完成品を顧客が見てから決定される。
詳細仕様は使用者がプログラムを動かしてから固まる。
プログラマーの格言4（盗作多し）
私は、ソフトウェア設計には 二つの方法があるという結論に達した。
一つは、欠陥がないことが明らかなほど単純にする方法である。
もう一つは、明らかな欠陥がないほど複雑にする方法である。
C.A.R.Hoare
プログラマーの格言5（盗作多し）
コードは開発現場で書くんじゃない！ 納品先で書くんだ！
デバグは納期前にするんじゃない！ 運用後にするんだ！！
プログラマーの格言6（盗作多し）
画面は青かった 。
（通信用語の基礎知識 より）
プログラマーの格言7（盗作多し）
「無理です！」は言ったもん勝ち
プログラマーの格言8（盗作多し）
文句があるならお前がやれ
プログラマーの格言9（盗作多し）
プログラマー殺すに刃物はいらぬ、仕様を三回変えれば良い
プログラマーの格言10（盗作多し）
まず、他人を疑え、疑われた人が解決してくれるかもしれない。
（注 「まず自分を疑え」の方が一般的）
プログラマーの格言11（盗作多し）
開発に終わりはない。リリースがあるだけだ。
プログラマーの格言12（盗作多し）
仕様確定がどんなに遅れても納期は変わらない。
これを「納期不変の法則」という。
プログラマーの格言13（盗作多し）
顧客は水と仕様追加はタダだと思ってる。
プログラマーの格言14（盗作多し）
金払いの悪い客ほど口うるさい。
プログラマーの格言15（盗作多し）
開発スケジュールは小学生でもできる算数を無視して作られる。
営業とは1＋1が2であることを理解できない人の集まりである。
プログラマーの格言16（盗作多し）
一人倒れればみんな倒れる。
プログラマーの格言17（盗作多し）
バグは夜更け過ぎに仕様に変わるだろう。
プログラマーの格言18（盗作多し）
良い仕様は一人の天才よりも三人の凡人を求める。
悪い仕様は百人の凡人よりも一人の天才を求める。
プログラマーの格言19（盗作多し）
オーダーメイドのソフト料金の30％は仕様の確認に当てられる。
30％は仕様の変更のためである。
30％はバグの検出のためにある。
初期仕様による作成に関わる料金の割合は結果として10％しか残されていない。
プログラマーの格言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（盗作多し）
「はい、できます」と言いそうになったら10秒数えろ。
プログラマーの格言49（盗作多し）
人はおよそ他人の失敗から学ぶことのできない動物だ。
値切る、変える、増やす、急かす、誰もみずほの失敗を教訓にしようとしない。
プログラマーの格言50（盗作多し）
ベテランが気力を取り戻すための魔法の言葉
「それでも、昔に比べれば・・・」
新人がやる気を出すための魔法の言葉
「この仕事が終われば・・・」 彼らは、仕事の谷間など無いことをまだ知らない。
プログラマーの格言51（盗作多し）
納期とは開発現場を会社から顧客先に変更する日である。
プログラマーの格言52（盗作多し）
プログラマー・ＳＥ・マネージャーなどは職種ではない。役職だ。
プログラマーの格言53（盗作多し）
営業は最もやっかいな顧客である。
プログラマーの格言54（盗作多し）
問題に対してすぐさま解決法を決めつけるプログラマが多すぎる。
彼らは 1分考えて、1日をコーディングに費やす。
1時間考えて 1時間でコーディングする代わりに。
Jon Bentley
プログラマーの格言55（盗作多し）
綺麗な仕様では、バグが出ないとわかったの。汚れているのは、 設計なんです。何故こんなことに・・・
プログラマーの格言56（盗作多し）
運用後のデバグはバグを呼ぶ。
プログラマーの格言57（盗作多し）
追加要求を確定すると納期は確定できない。納期を確定すると追加要求を確定できない。これを納期と追加要求の不確定定理と呼ぶ。
プログラマーの格言58（盗作多し）
三つのデバグは一つのバグを産む。これをバグのエンドレスループという。
プログラマーの格言59（盗作多し）
いやな予感は必ず当たる。
しかしプログラマーは、その悪い予感に対応しようとはしない。それはＳＥの仕事だ。
プログラマーの格言 60（盗作多し）
修羅場を解決できる方法は、唯一、顧客が金を出してくれることだけだ。
プログラマーの格言 61（盗作多し）
素人のオペレーターはバグを発見する天才である。再現不能。
プログラマーの格言 62（盗作多し）
打ち合わせのたびに仕様が変わる顧客の操作マニュアルは、できあがったＰＧを操作しながら作成される。
プログラマーの格言 63（盗作多し）
分からないときはＩｎｔｅｇｅｒよりＣｕｒｒｅｎｃｙ。ＣｕｒｒｅｎｃｙよりＶａｒｉａｎｔ。安全第一。（ＶＢプログラマーより）
プログラマーの格言 64（盗作多し）
ああ、それはマイクロソフトの仕様です。
プログラマーの格言 65（盗作多し）
プログラマーが不満に思う仕様は顧客も必ず不満に思う。
プログラマーの格言 66（盗作多し）
プログラマーに必要なスキルは、交渉・スケジュール管理・業務分析・提案・設計・言語・構築・保守・運用。
ＳＥに必要な能力は、これから言語・構築・保守・運用を引く。
マネージャーに必要な能力は、さらに業務分析・提案・設計を引く。
営業に必要な能力は、さらにスケジュール管理を引く。
プログラマーの格言 67（盗作多し）
健康だからこそ、不健康なことができるんじゃないか。
（格言どもより）
プログラマーの格言 68（盗作多し）
し、仕様よ、仕様。でも、ちょっとだけ仕様じゃないの。
（fortune (back number)より）
プログラマーの格言 69（盗作多し）
それは、あなたが言った仕様ですよ。
プログラマーの格言 70（盗作多し）
開発室の窓は開かない。その理由は昔・・・
プログラマーの格言 71（盗作多し）
腐っても仕様。（fortune (back number)より）
プログラマーの格言 72（盗作多し）
SE: しようがないな。
PG: コメント もありません。
（作り人知らずのＰＧの問い合わせに行き詰まった状態）
プログラマーの格言 73（盗作多し）
どうして、こんなことちょいちょいとできないんだ。
ちょいちょいとできたものに、あなたがちょいちょいと品質確認の印をついてくれるのでしたら。
プログラマーの格言 74（盗作多し）
動かねぇバグは、ただのバグだ。（動くバグは仕様にできる）
プログラマーの格言 75（盗作多し）
今日の害虫駆除でバグも死んでくれないかな。
え、Ｗｉｎｄｏｗｓも死んでしまいますよ。
プログラマーの格言 76（盗作多し）
顧客は最悪を考えず、最悪に対応しようとするのを悪質な費用のぼったくりだと思う。
ＳＥは最悪に備え、最悪に対応しようとする。
ＰＧは最悪を誰よりも予想し、最悪を無視する。
プログラマーの格言 77（盗作多し）
バグを起こさない唯一の方法は プログラムをくまないことだ。
次善の方法は、スケジュールと人員を定めた後は仕様の変更や追加の度にプロジェクトを見直すことだ。
プログラマーの格言 78（盗作多し）
共同責任はプログラマーの責任。管理職？ 何それ？ おいしいの？ 食ったこたねぇなぁ。
プログラマーの格言 79（盗作多し）
もし転職するとしたら、定時で帰ることを「逃げる」と呼ばない職業がいいですね。
プログラマーの格言 80（盗作多し）
職業プログラマーにとって美しいプログラムとは、単純で素朴なロジック、簡単で基本的なコマンド、豊富なコメント、つまり新人に近いプログラマーが初めて見ても直ぐに修正できるようなプログラムである。
そのためには単純で簡単な美しい仕様が必要である。しかし残念ながら顧客は素人だ。何故か凝りたがる。
プログラマーの格言 81（盗作多し）
設計者が、設計以上のものを 製造者に求める分野なんてあるはずがないじゃないか。
プログラマーの格言 82（盗作多し）
仕様書に書かれていないことをしても、また、仕様書に書かれていることだけしてもＳＥはプログラマーに文句を言うものだ。だからプログラマーは仕様書に書かれていることだけしかしない。
プログラマーの格言 83（盗作多し）
ＳＥがプログラマーに言う「常識」は、三時間毎に変化する。
プログラマーの格言 84（盗作多し）
自分の仕様書を読んでください。動かないのが仕様です。
プログラマーの格言 85（盗作多し）
無理ですというのは一日を何時間で計算しているんだ。一日は 3人日、一ヶ月は4．5人月あるんだぞ。
プログラマーの格言 86（盗作多し）
工数は半分、単体テストを引き、システムテストを半分しにて、 納期は運用後二ヶ月を足して計算しています。
プログラマーの格言 87（盗作多し）
金がもらえる仕様変更は受注要件だが、金が付かない仕様変更はＳＥの仕様の確認ミス 、とプログラマーからは見なされる。
プログラマーの格言 88（盗作多し）
もう疲れたよ。なんだかとっても眠いんだ。帰っていいかな。
（疲れただろ、僕も疲れたよ。なんだかとっても眠いんだ。仕様でいいよ、もう）
Recent Comments