A Better Me on Software Engineering. Review of Code Complete by Steve McConnell Chapter 3 & 4
Chapter 3
“Measure twice, cut once” is a carpenters rule that is used to get an accurate measure before cutting and the same applies to software construction.
This concept allows for a software construction team to only do construction once, but in case where it is not applied a team ends up doing construction more than once.
Doing the most expensive part of the project twice is as bad an idea in software as it is in any other line of work. Measuring twice in software construction gives a team some prerequisites to follow before starting the construction process.
3.1 Importance of prerequisites
Programmers who build high quality software have something in common, that is the use High quality practices. The practices emphasize quality at the beginning, middle and end of a project.
Your plan is as good as your end result, meaning if you start the process with designs for a Pontiac Aztec, you can test it all you want to, and it will never turn into a Rolls-Royce.
Do Prerequisites Apply to Modern Software Projects?
Some people say that prerequisites do not apply, I tend to think they are speaking hypothetically. There is not research that supports their thoughts and they further go ahead to pick out examples of prerequisites that have been done poorly and then point out that such work isn’t effective.
I strongly differ with this point of view. A set of well done prerequisites can lay the foundations of proper software construction and contribute to the timely completion of the project. Project prerequisites tend to push for clearing major risks out of the way as early as possible so that the bulk of the project can proceed as smoothly as possible.
Causes of Incomplete Preparation
Lack of incomplete prerequisites to guide you through the project will certainly have the project take longer compared to if you had complete prerequisites.
The WISCA or WIMP syndrome: Why Isn’t Sam Coding Anything? or Why Isn’t Mary Programming? is one of the reasons a team might end up starting work on a project without having completed their prerequisites. This happens when your project boss has no understanding of the importance of prerequisites in a project and all they want to see is code.
Foolproof Argument for Doing Prerequisites
Appeal to Logic — It only makes sense to plan before starting to work on a project whether big or small
Appeal to Analogy — Building software is like any other project, other projects like building a house require planning in terms of architectural drawing, building blueprints and approvals, why not plan for a software project?
View planning more like a food chain where a designer consumes requirements, programmers then consume the designs by the designer, users consume the software. If this does not occur in the correct order there must arise a problem during the construction process.
Appeal to Data
Studies over the last 25 years have proven conclusively that it pays to do things right the first time. Unnecessary changes are expensive.
3.2 Determine the kind of software you are working on
coming soon…
More coming I am still writing…