SE 477 Principles and Practices of Software Engineering

Journal for Dennis Mumaugh

Entry April 3, 2008

Support or refute these Software Engineering myths.

Myth # 1

If we get behind schedule, we can add more programmers and catch up.

Brooks discusses this. There is time needed to bring the new people up to speed. The current developers must take the time to do this thus further delaying the schedule. The more people the more time it takes to communicate, gain consensus and make plans.

Myth # 2

If I decide to outsource the software project to a third party, I can just relax and let that firm build it.

Tell that to the people who off-shored to foreign countries. It takes more effort to manage the project. Requirements must be more specific, more detailed designs needed, extensive testing. In addition, there is less communication and delayed communication. Expect about 50% effectiveness at best.

Myth # 3
A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.

This may never happen. General statements tend to be ambiguous and leave out many details. This can result in starting in the wrong direction and potential of causing the project to fail.

Myth # 4

Project requirements continually change, but change can be easily accommodated because software is flexible.

This is true only if one plans for the changes and designs with potential change in mind. An iterative methodology is good for this.

Myth # 5
Until I get a program running I have no way of assessing its quality.

There are software quality measures at every stage of development. One can assess the quality quantitatively and using design heuristics.

Myth # 6
Software Engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

This is only true if you use a process heavy methodology. Agile and other methodologies reduce documentation to the minimum needed.