Chapter 1
In the introduction of the book, the importance of an engineer is emphasized. The author, Jack Ganssle, gives a renewed meaning to the term and job description of an engineer. In todays society, most people know, recognize, and put high value on the word doctor and the implications of owning a title like this. Ganssle puts the meaning back into the title description of an engineer. He says that in the 1800's, engineers were more like doctors, in a sense that they were recognized as the pioneers of tomorrow.

Ganssle describes an engineer as todays problem solver, the gap between engineering researchers an their theory to the consumers and their engineered gadgets.

I think the point Ganssle stresses is that engineering is still a noble profession, just as any other respected profession today.

Chapter 2
The main ideas in this chapter are that code/firmware is expensive and better design and development methods make an engineering individual, group and company more valueable. Therefore, a new method of firmware production is required. Ganssle quotes the ideas of the Capability Maturity Model (CMM) for software development from www.sei.cmu.edu. The key here: there are distinct software development maturity levels each company is executing. At level 5, a company is the most ideal and very efficient at producing code.

On thing that Ganssle discusses is the motivation and drive for engineers and engineering companies. The drive for engineers and engineering companies is the customer that buys their product. This is the main reason engineers develop and companies survive. Customer service is the last thing I would have thought of as a worry for an engineer, but obviously it is a necessity for our survival in the workforce.

For the final thought of the chapter: "If you're a process cynic, if you disbelieve all I've said in this chapter, ask yourself one question: do I consistently deliver products on time and on a budget? If the answer is no, then what are you doing about it?" Ganssle brings up a very good point protecting the right to more efficient code producing techniques.

Chapter 3: Stop Writing Big Programs A rule of software engineering is that program logic and design complexity to not scale linearly with size. What the author means is complexity grows almost exponentially with code size. Keeping code short and simple is the best way to get things done.

A measure of this rule of thumb is encapsulated in the Consturctive Cost Model (COCOMO), coined by Barry Boehm. The main idea is that the amount off effort is exponentially proportional to a constant C, multiplied by the lines of code produced to the M power.

In addition to big project and code complexity is the number of people invovled in a huge software project. Communication between everyone involved in the project is a productivity issue. As the number of people increases, the number of communication lines increase. The number of communication lines and the number of people are related mathematically in the book.

The solution to large code projects: partitioning. Partitioning the code into small units that perform specific functions and dividing these tasks for different groups of coders is a great way to get big projects coded on time and with less bugs. Debugging is also made easier because of this.

The last idea in the chapter has to do with developing software little by little. Some of the concepts Ganssle talks about involves developing working versions of our code increment by increment, just as how we are approaching the problem in our class now.