Facts and Fallacies of Software Engineering

這本書指出軟體工程的一些事實跟謬誤，還不錯啦。

People

Fact 2

The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

說得很好，不過很多老闆似乎並不這麼想。

Fact 3

Adding people to a late project makes it later.

這算人月傳奇的一種吧。反正大家都認為把人塞進專案內，專案就可以加速。事實上並不是這樣的。

Fact 4

The working environment has a profound impact on productivity and product quality.

工作環境很重要！我喜歡這句話：You must get good people, and then you must treat them well, especially in providing a workable environment.

不過工作環境包含工作氣氛嗎？我的工作環境不錯啊，不過氣氛很差。

Tools and Techniques

Fact 6

Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only (a) if their value is seen realistically and (b) if patience is used in measuring benefits.

可惜大部分的老闆似乎不太瞭解這一點。原因當然是專案很急啊，哪有這個時間去等。

Fact 7

Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.

這個應該是工程師的現象。新奇的東西不玩玩看實在是很對不起自己，但是玩完之後就謝謝再聯絡。

Estimation

Fact 8

One of the two most common causes of runaway projects is poor estimation.

Do we have estimatted something? Hahaha.

Fact 9

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

需求未清楚定義之前就先作評估，這當然是錯的。不過很可悲的是，大家好像都是這樣搞專案的。

Fact 10

Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

同樣地，要評估一件事情，應該是由要作這件事情的人去評估，而不是讓經理人去作。大家都會這樣啦，不過最終決定權還是在經理人手上......。

Fact 11

Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.

廢話！

Fact 14

The answer to a feasibility study is almost always "yes."

嗯嗯，這是理想狀態啦。

Reuse

Fact 19

Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.

Requirements

Fact 23

One of the two most common causes of runaway projects is unstable requirements.

是啊，需求一直改來改去，根本無法專心把設計搞定啊。

Design

Fact 28

Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.

所以才會需要作 refactoring。

Testing

Fact 32

Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly to 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.

工具不是萬能，但是有助於測試的當然是好工具。

Fact 35

Test automation rarely is. That is, certain testing processes can and should be automated. But there is a lot of the testing activity that cannot be automated.

同感，有些東西硬要用自動化測試，實在是強人所難。出一張嘴當然是很簡單啊，做了才知道。

Reviews and Inspections

Fact 37

Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run.

Did we have ever code review? Hahaha.

Fact 38

In spite of the benefits of rigorous inspections, they cannot and should not replace testing.

廢話。

Fact 39

Postdelivery reviews (some call them "retrospectives") are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do postdelivery reviews.

深有同感。

Fact 40

Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.

Peer reviews? 那是甚麼？可以吃嗎？

Efficiency

Fact 52

Efficiency stems more from good design than from good coding.

架構不好效能就差，而且不改架構幾乎是無解。

Fact 53

High-order language (HOL) code, with appropriate compiler optimizations, can be about 90 percent as efficient as the comparable assembler code. Or even higher, for some complex modern architectures.

compiler 萬歲！

Fact 54

There are tradeoffs between size and time optimization. Often, improving one degrades the other.

修過 CS 的 Algorithm 就能夠深深體會這句話。有一好沒兩好。

Testing

Fallacy 7

Random test input is a good way to optimize testing.

Random test 的大問題是，如何知道出問題的是哪個部份。假設整個系統使用 Random test，假設它出現 test fail，怎麼知道這個 fail 是如何產生的呢？因為不能複製 fail 的話，根本無法對這個 fail 除錯，那 run random test 有何意義呢。

Fallacy 10

You teach people how to program by showing them how to write programs.

所以教人家寫code 不如教人家看 code。