プログラマとプロマネのあいだ

プログラマもやるし、プロマネもやるし、たまに似非アーキとか営業っぽいこともやる

その場しのぎプログラミング

久々にオレンジニュースチェックしてたら見つけた。
もうこのエントリ、超同感。だからこそのperlだったりしますよね。
Rubyや、PHPや、Pythonでもよいのだが、商用UNIXに標準インストールされているのがperlだけだったりするので、やっぱりperlが一番良いという結論になったりする。
それから、WSHだったり、VBScriptだったり、HTAだったり、Excel VBAってのも、なんかあまり注目を浴びていないような気がするけれども、Windowsで開発してUNIXへデプロイとかいうパターンが多い昨今だと、やっぱり重要だったりします。
あと、最近たまたま触れる機会があったC言語ってのも、Light Weightでもなんでもないのだけれど、ちょっとしたツール作るとかでは使えるはずなので、多少は出来るようになっておかないとなぁとか思ったりしています。
よく、面倒な繰り返し作業を効率化するのに、プチツールを作ったりするのですが、それがまた後から使えるケースってのがあったりするんですよね。で、そんなとき、

  • ツールを使わないで作業した場合の作業量=a
  • ツールを作成する作業量=b
  • ツールを使って作業した場合の作業量=c
  • 作業回数=n (他の人にツールを横展開すれば、さらに効いてくる可能性あり?)

で、

a * n > b + c * n

になれば、ツールを作成した方がよいのですが、当然bが大きくなればなるほど、この式の不等号が逆転する可能性が高くなり、「時間がかかるようでは意味は無い」という理論も当然です。
日ごろ、「めんどくさいなぁ」と思った瞬間に、上記a,b,cの作業見積もりを脳内ではじき出し、ツールを作るか否かの判断を下すのですが、思ったよりツールの作成に時間がかかってしまってbが大きくなったり、思ったよりツールが中途半端になってcが小さくならなかったりすることもままありますね。
このような事態に陥らないためにも、日ごろの修行が重要だと思うわけです。
(これ、昔社内論文で書いたネタほとんどそのままだわ。。)