あまりに見事に酷いお話(http://d.hatena.ne.jp/minekoa/20080125/1201263076)

うわー……。これ言ったの、COBOL出身のおじいちゃん技術者ですか？
そうじゃなければ、よっぽどひどい先生についちゃったのか……。

ちなみに、昔、「他社の入ったばかりの新人のすごいコードをつきっきりでリファクタリング」という妙な仕事をやったことがあります。彼の名誉のために言うと、すごいコードになっちゃったのは、前任者が倒れてしまったのをあわてて直していったらそんなになっちゃったためで、元からすごいコードにしようとしていたわけではないですが。
三日ほどかけて怒鳴りつけながらリファクタリングした結果、何とか動くものにはなったのですが、いつ彼が切れるかと非常にどきどきした記憶があります(^^;)。仕事先の人を怒鳴りつけるなんてのは、なかなか出来る経験ではないです(もうやりたくないけど)。
一から作ったほうが速いよなぁ、とは思ったのですが、その会社のそのプロジェクトではプログラマーは彼一人しかいなかったので、何かあったときに彼が直せないとなにが起こるかわからないということもあって、無理やりたたき上げるしか選択肢はなかったのです。おかげで、何とかプロジェクトは終了し、やった作業自体はそこの会社にも、元受にも好評だったと聞きます。
まぁ、そうじゃなければ、そのプログラマーをプロジェクトからはずすのが一番簡単なんですけどねぇ……。

それはさておき。
前項で書いた新人さんではなく、これまた別のプロジェクトで聞いたことがあるせりふがいろいろと。

• Q. 関数が尋常じゃない長さ(700行)なので可読性のため分割しませんか
• A. 関数コールであちこちに飛ぶ方がかえって読みにくい

「関数の中で#includeとか、ソース先頭で#include "hoge.c"やめませんか？」と言って、嫌がられたことはあります。分割コンパイルとリンクという概念がないそうで……。

• A. そもそも、コードの可読性は品質には影響しない。可読性をあげて良いことがあるのか。

「コードの可読性とパフォーマンスは相反する」といわれたことはあります。わかるけどさー。

• Q. とにかくコードが酷い。そもそも 構造化プログラミング は知っているのか
• A. 構造化プログラミングは知っている。しかしいつでも適用できるモノという訳ではない
• A. 見解の相違はあるかもしれないが、これが我が社の文化（伝統的スタイル）であり、他の社員でもメンテナンスする関係上、このスタイルを変えるつもりはない

「オブジェクト指向は社内規定で使用禁止」と言われたことならあります。

• Q. コメントが殆どない。もう少し何とかならないか
• A. コメントがあるとコードはかえって読みづらくなる

本当に意味がある関数名と、処理が明らかに見える引数の名前ならばある程度は容認できます(もっとも、関数のインターフェースにはコメントがないとどうにも……)。
でも、こういうこという所に限って「FUNC001_001(int ARG1)」なんて名前がつけられてるんですよねー(^^;)。

• Q. 一度でもテストすれば発覚するような不具合が多すぎる。テストはしたのか？
• A. テストはしていない。これからは行うようにする。

コンパイルの通らないソースを持ってきて、「うちでは動いた」と言い張る人なら見たことがあります。
大陸系の人だったので、言葉が通じていなかったのかと自分の耳を疑いました。

だめコードの話は盛り上がりますね(^^;)＜おーい