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

Ganssle describes an engineer as todays problem solver, the gap between the engineering theory researcher and the engineered gadget consumer.

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 valuable. 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.

One thing that Ganssle discusses is an engineer's motivation and drive. The drive for engineers and engineering companies is the customer that buys their products. Customer product satisfaction is the main reason engineers develop and companies survive. Customer service is obviously it is a necessity for an engineers survival in the workforce.

Here is 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 Program logic and design complexity do not scale linearly with size is a rule of software engineering. The author means 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 of effort is exponentially proportional to a constant C, multiplied by the lines of code produced to the M power.

The number of people invovled in a huge software project is a big factor in the complexity of the design. Communication between everyone involved in the project is a productivity issue. As the number of designers increases, the number of communication lines increase. The number of communication lines and the number of designers 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. Partitioning makes debugging easier.

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.