Technical Debt

Leading Lean Software Development: Results Are not the Point (Addison-Wesley Signature Series)

• 作者: Mary Poppendieck
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2009/10/31
• メディア: ペーパーバック

ちょっと長い引用ですが、Chapter 1 「Ｓｙｓｔｅｍｓ Thinking」に書かれていて、私が読んだ際に、ほとんど赤線を引いた「Technical Debt」です。

Technical Debt


We know that all successful software gets changed. So if we think we’re working on code that will be successful, we know we need to keep it easy to change. Anything that makes code difficult to change is technical debt. We know that
technical debt drives the total cost of software ownership relentlessly higher,
and that eventually we will have to pay it off or the system will go bankrupt.
And yet . .

1. We tolerate obscure code, instead of making sure that all code reveals its
   intentions to the next person who comes along. Developers, especially
   apprentices, should be taught how to write “clean code”: code that is
   simple and direct, with straightforward logic. Senior technical people need
   to ensure that messy code, even if it passes the tests, is never admitted into
   the code base.


2. Far too often we don’t take the time for refactoring: consolidating changes
   into existing code. Refactoring is essential for iterative development. Adding new features to existing code creates complexity, ambiguity, and duplication; refactoring pays down the debt.


3. We run regression tests on our systems before deployment. At first they are
   quick, but with each addition of code, regression tests take longer and
   longer and longer. As the regression deficit grows, we increase the interval between releases. The only way to break this unending cycle of increasing release overhead is to decrease the regression deficit. If we had started
   with automated test harnesses back when the code base was small and
   added to and maintained them, we could make changes to our code almost
   as quickly today as when the code base was new.


4. We know that dependencies are one of the biggest generators of technical
   debt, and yet we are ambivalent about replacing obsolete systems with
   massive dependencies. We must develop, and migrate to, architectures that
   minimize dependencies. We have known for a long time how to do this:
   Focus on information hiding and separation of concerns.


5. We branch code for many reasons: to isolate new development, to focus on
   an individual application, to create parallel feature sets. And we know that
   the longer two branches of code are apart, the harder they will be to
   merge. And yet we wait for days to build our code, and worse, we delay
   system testing until the end of development. We don’t realize that this isn’t
   necessary anymore; the big bang is obsolete.

We need to expose technical debt for what it is: a costly burden to be avoided
lest it lead us into bankruptcy. Chapter 2 will look at software development
through a technical frame and discuss solid techniques for avoiding technical debt.

訳す時間がないので、じっくりと辞書片手にお読みください。時間が取れた時に訳を付けてみたいと思います。

（「Deliberate Practice」は、訳を追記してあります）