JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。 このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。TDDと契約による設計(Design by Contract)の比較や、システムとビジネスドメインモデルを調和させるためには、事前にどれくらいのアーキテクチャ設計をしておかなければならないのか、などが議論されている。（翻訳：近藤 修平 - (株)永和システムマネジメント）
私たちは毎日コミュニケーションに失敗している。失敗は取るに足りないものから悲惨な結果をもたらすものまで様々だ。残念なことに、私たちには口論やケンカやもっとひどいことになるまで、コミュニケーションの失敗の本質について注意を向け自分たちのやりとりを分析しようとしない傾向がある。コミュニケーションの失敗はチームワークが重要な今日の世界のビジネスにおいて競争上の優位を得るための最も大きな障害である。この記事では J. B. Rainsberger 氏が祝日の挨拶を例に、効率的なコミュニケーションと信頼の構築、そしてチーム作業を行うための秘密兵器のひとつを教えてくれる。
ソフトウェアを新しい需要や要件に適合させることが困難になるほど、アーキテクチャを更新するためにソフトウェアを再構築するという誘惑は強くなる。その取り組みはむしろリスクが高く、適切な戦略を採用することが不可欠である。
JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。
Fiona Charles氏によるStickyMindsでの最近の記事は、問題を抱えたプロジェクトの舵取りについて触れている。「前進のための融通の利かないプロセスのための時間ではない」と強調し、プロジェクトを好転させるのに役立つ貴重な洞察を提供している。
ソフトウェアプロジェクトにかかわる多数の決断は、生産性が第一に考慮される。プロジェクトが成功し、その市場が成長し、ドメイン知識とクライアントニーズの両方で複雑さが増している場合、特にその傾向が強くなる。適用範囲が予期せぬ転換になる可能性は高く、プロダクトにはカスタマイゼーションが益々必要になる。
今日のソフトウェアコミュニティにおける努力の多くは、ソフトウェア開発のプロとビジネスピープルとの間のギャップを解消するための橋渡しを目標としているが、一部のブロガーは問題をすこし異なった視点から見ており、開発者と彼らが作るソフトウェアとの間のギャップを強調している。
Rails、Hibernate、他のORMツールに使用されているActive Recordパターンはdatabase rowのオブジェクトへのマッピングを許容するデータ持続パターンである。しかしながらこの実用的なツールはBob Martin氏によると混乱の源であるそうだ。 柔軟性を保つにはBob Martin氏はActive Recordをアプリケーションから分離させることを提案しており、そうすることによって後者はオブジェクトの周りで単一でデザイン、また構成することができるのである。
