Software Engineering discussion

Although written almost as an aside, I think that the "developer as estimator" topic is really important. Developers have the power, consciously wielded or not, to low-ball an estimate if they want to do a piece of work, and to high-ball an estimate if they don't. This means that managers have to build an inflation/deflation factor into estimates to compensate for this natural bias. I think that this topic deserves its own chapter.

As far as the second-system effect itself, although a very popular legacy from this book, I don't really totally agree with the way it is presented here. I think that there are two factors at play. First, customer's often ask for things, and developers often add things, that end up not being used. Statistics vary, but it appears that at least 50% of function in most products isn't really needed. Second, there is a natural feature creep in all products, which comes from responding to customer feedback, and from the desire to add function to justify the additional revenue for a new release. The result of this, in many cases, is bloated software. Word is a prime example. It takes incredible discipline to avoid this problem. I don't know if this is what Brooks really meant to discuss, but I think it is a more prevalent problem.

I liked this chapter for the two areas you pointed out.

Comparing a developer's estimate to bidding a construction contract is a nice analogy that is new to me. I think that's a great lesson to learn and understand.

When reading the "second-system effect" parts of this chapter, I was thinking about "one hit wonders" in the music business. I think this is often called the Sophmore Slump. Success is rare and expectations are higher. I think your feature creep and bloat are also good reasons for the "second-system effect".