ソフトウェア品質の低下という認識は、多くの場合、視点の問題です。個人用コンピューティングの初期段階において、ソフトウェアは現代の基準から見れば頻繁に「ひどい」ものであり、極端な不安定さが特徴でした。その主な要因の一つは、物理的な配布によって課せられた「品質の最低ライン」でした。ソフトウェアはフロッピーディスクやCDで出荷されていたため、企業は製品が「箱から出してすぐに」動作することを保証するチャンスを一度しか持てませんでした。これは、ソフトウェアを無期限に更新およびパッチ適用できる現代の継続的デプロイメントとは対照的です。このような配布上の制約にもかかわらず、Windowsのような初期のシステムは、バグのあるデバイスドライバや、終了したプログラムからリソースを回収できないオペレーティングシステムの失敗によって引き起こされるカーネルパニック、すなわち頻繁な「Blue Screens of Death（ブルースクリーン）」に苦しんでいました。
システム全体のクラッシュに加え、ユーザー体験はデータ損失というトラウマによって定義されていました。初期のアプリケーションには信頼性の高いオートセーブ機能が欠けていることが多く、バッファへの書き込みをフラッシュすることに失敗することもあったため、一度のクラッシュで数時間の作業が消去されることも珍しくありませんでした。この信頼性の欠如は、ユーザーの間に永続的な心理的習慣を作り出しました。オートセーブが標準となっているGoogle Docsのような現代的な環境であっても、多くのユーザーは進捗を失うことへの根深い恐怖から、反射的に「Ctrl+S」を押します。さらに、ソフトウェアはハードウェアによって強く制約されていました。限られたメモリとCPU速度は、ユニット数が255を超えるとゲームがクラッシュするといった特定のプログラミング上の欠陥を招きました。これらの制限を管理するために、一部のハードウェアには、古いタイミング依存のアプリケーションを壊さずに実行できるように、プロセッサを意図的に手動で減速させるための「TURBO」ボタンさえ備わっていました。
現代のソフトウェアは、肥大化、極端な複雑性、そしてレイテンシの増加という異なる一連の課題に直面しています。ソフトウェアの「マイクロレベル」、つまり個々のコード行やライブラリは、はるかに信頼性が高くテストも容易になっていますが、「マクロレベル」のアーキテクチャは変化しました。多くの現代的なアプリケーションは現在、複雑なWebベースの構造として動作しており、ユーザーの操作に顕著な遅延を引き起こす可能性があります。この変化はトレードオフを意味しています。私たちは過去の脆弱性やハードウェア固有の癖を、より安定しているものの、著しく複雑で抽象化されたコンピューティング環境と引き換えにしたのです。一次ソースは、現代のソフトウェアは「キッチンに料理人が多すぎる」ためにしばしばより遅く複雑であるものの、1990年代のシステムよりも根本的に安定していると指摘しています。