以上の機体の状況から、202便は夜明け前の巡航中に空中分解して墜落したと推定された。まず第二エンジンのプロペラに異常振動が起こりエンジンが崩壊し、それを引き金に機体に異常振動が起こり、水平尾翼の一部が脱落し、エレベータが上向きになり仰角が増大した。そのため主翼にかかる上向きの力に左主翼が耐えきれず切断して脱落した。さらに残された機体も左主翼が消失したため機首を下げる力と尾翼からの機首を上げる力が衝突し、機体尾部が引き裂かれて空中分解して墜落した。なお、この第二エンジンを崩壊させたプロペラの異常振動の原因であるが、プロペラブレードの設計ミスが原因であると推測された。それはボーイング377が、空冷四重星型28気筒で、71,450cc の排気量から 3500 馬力を搾り出すプラット・アンド・ホイットニー R-4360-B6 「ワスプ・メジャー」という、最大級のレシプロエンジンを搭載しながら、プロペラはそれよりも馬力が低いエンジンを想定したものを多少強化した程度であり、プロペラ内部が空洞（中空）のタイプであった。そのため、エンジンが生み出す推進力に対して耐え切れずに破断し、エンジン崩壊を招いたことが直接の原因とされた。しかしアメリカ連邦民間航空局（CAB）がボーイング377のレシプロエンジンに装着されていた中空式のプロペラを、ソリッドタイプ（中実、ムク）のプロペラに変更するよう勧告を出したのは、3年後に再びボーイング377が飛行中にプロペラを飛散させる事故を起こした後であった。また、原形機となったB-29爆撃機や同時期に就航したDC-7も含め、大型レシプロ機はエンジンの複雑な構造を原因とするエンジントラブルが多かった。そのためパンアメリカン航空のボーイング377は、その後もエンジントラブルで不時着水や墜落する事故を起こしている。
202便が墜落した地点は予定された航路下であったが、現地の地形は複雑であり、附近の川も小さかったため、飛行艇による搬出も不可能であった（当時は現在ほどヘリコプターが発達していなかったため）。またアメリカ軍による落下傘部隊投入も、生存者がいないことや地形のため、機体や遺体の搬出は難しいとして断念された。そのため、調査隊を陸路派遣することになった。事故調査団が40マイル（約60km）まで飛行艇で向かい、そこから陸路で墜落現場に到着したのは5月16日であった。しかしこの調査隊は途中で7名以外は引き返した上、水や食料が欠乏し人手不足のため撤退を余儀なくされた。そのため、最初の調査団は、搭乗者全員が死亡していたこと、そして202便の残骸は、おそらく原住民が衛生のために火をつけたと見られる火事で胴体が焼失したことを確認しただけであった。大幅に人員と装備を増強した第二次調査団が墜落現場に入ったのは事故から4か月経った8月15日であった。そこで202便の残骸が大きく3つに分かれて墜落していることを発見した。第二エンジン附近の主翼、反対側の左翼主翼、胴体に分かれていた。なお第二エンジンとプロペラは発見されなかったが、そのことが最初に機体から脱落した証拠とされた。
まず、そのプログラムの目的、さらには「本当に解決したい問題は何なのか」ということについて十分な検討が必要である（ワインバーグの著書などを参考のこと）。続いて、全体のスタイルをおおまかに2つに分けると「トップダウン設計」と「ボトムアップ実装」になる。「なんとかの設計と実装」といったようなタイトルの本が多くあるように、どちらも重要だが、一般に対象についてよくわかっているものについてのプログラミングでは前者のスタイル、よくわかっていない場合は後者のスタイルとする。「設計された通りに実装することは不可能」といった場合に開発体勢の問題などから正しい対処がされないまま、設計と実装がちぐはぐになったプロダクトは悲惨である。また反復型開発では、あまりに大きなプログラムを一方通行のプロセスで書くことは最初から避けるものとされる。目的のプログラムを書き始める前に、まずテストを書く、というスタイルもある（これを、「テストファースト」という。詳しくは、テスト駆動開発を参照）。あるいは対象が有限オートマトンやプロセス計算など、形式手法的な方法でモデル化できるのであれば、まずはそのようにすべきである（本来はモデル主導というのはそのような意味のはずである）。最初の段階として、トップダウン設計では軽量プログラミング言語や、非形式的な記述が適している場合には擬似言語（擬似コード）などで全体設計を検討する。ボトムアップ実装では、階層構造の「葉」にあたるサブルーチンの実装を検討する。なお、流れ図（フローチャート）はコンピュータの黎明期である1940年代後半に、当時のプログラムは機械語で読むのも書くのも難しかったことから、補助のために使われその当時には有用性が高く（en:Herman Goldstine#The First Draftに当時の流れ図がある）、MIXという機械語を使っている教科書『The Art of Computer Programming』などでは使われているが、現代のプログラミング言語でも有用と信じられていることもあるようである。プログラミングの過程で、ソースコードを記述することを特に指してコーディングという。元々は機械語が符号であること、またはアセンブリ言語のニモニックがまるで暗号みたいである（正確には「コード」は暗号の1分類。コード (暗号) を参照）というところからコンピュータプログラムに「コード」という語が使われ、それを書く作業というきわめて限定された意味の語だったが、近年はHTMLを書くという意味にも使われるなど濫用され気味である（なお、デモシーンでは機械語のテクニックを駆使して高効率のプログラムを書く、というような本来の意味に近い意味で使われている）。可能な限り避けたいものではあるが、プログラムにはバグ(bug)の混入が避けられない。場合によっては仕様にバグがあることもある（もっとひどい場合には標準規格のようなものでもバグがある）。デバッグ(debug)とはバグを取る作業であり、プログラミングの過程に必要なものとして見積りなどでは含めておかなければならない。一旦の完成の後も、ある程度の期間使われるプログラムでは、使用しているうちに、プログラムの性能や機能に新しい要求が発生したり、プログラムの設定を変更する必要がでてきたり、テストにより発見できなかったバグが見つかることがある。このような事態に対応するため、プログラムを保守していく作業が必要になる。