プログラミングする時、

難しくて，複雑ではないのも

例えば，難しい数学公式があって，公式を理解するのが難しいが，公式のままにコードを書けば，割と簡単でで綺麗に書けます．なぜなら，数学の公式はすでに美しく抽象化さています．

しかし，実際では，美しく抽象化さてた数学公式を色々分解したり，ラッパしたり，継承したりして，抽象化が破壊さてれ，コードが複雑になるケースがよくあります．あるいは，数学の公式をそのまま書くと，パフォーマンスがよくないので，色々高速化を行う時，公式の抽象化が破壊されていまう場合もよくあります．

簡単で，複雑なもの

UIを作るとき，ボタンを追加するには難しくないはずだが，すごく複雑な場合があります．例えば，あるボタンをクリックし，複数の挙動が行われる場合，正しくコードを書ける人が少ないし，その部分まだ機能を追加するのも難しくなります．なぜなら，状態が多すぎて，いつ変わったのか，どこで変わったのか，どういう理由で変わったのかが複雑すぎて，うまくコントロールできません．

こういう時，ちゃんと設計したり，パタンを使ったりして，状態をうまく管理して，UI部品を抽象化する必要があります．

UI以外も色々例があります．例えば，２次元の三角形から作られた平面をすべての三角形ごとに２分割するプログラムを考えましょう．頭の中で一瞬で分割完了するのに，プログラムを書くとき，色々境界条件があって，結構面倒です．さらに，分割方法も色々あって，違う人でプログラムを書くと，全然違う方法で書くかもしれません，コミュニケーションも面倒になるし，直接他の人のプログラムを読んでも，なんでそうなるのかを時間かけて解読する必要があります．

難しくて，複雑なもの

マルチスレッドです．半分冗談ですが，確かに，マルチスレッドは難しくて，複雑です．それと違って，先の数学の公式で言うと，公式が抽象化されたが，境界条件が多いものは難しくて，複雑です．例えば，微分と積分両方数学公式でまとめられているが，（単純な多項式でも）積分のプログラミングは微分のプログラミングよりはるかに複雑になります．

工数見積もりの失敗の原因の１つ

プログラミングするとき、「この機能は簡単なので、２時間ぐらいで終われるだとう」と思って、実際にやってみると、１日以上もかかる場合が結構あります。また、１週間で終われると思って、実際は１ヶ月以上かかる場合もあります。

簡単で複雑なものを作る場合どれほど複雑になるのかを把握することが難しいです。だから、見積もりの失敗の原因の１つになると思います。