The book Code Complete by Steve McConnell is acclaimed as one of the must-reads for all developers and is extremely well known. It is comparable to a practical handbook full of tips and learning examples to develop more robust programs, and also introduces lots of concepts throughout that can be used to improve the development workflow as it evolves for projects.
Hence this is the first part of a seven-part book review series where I will be sharing my key takeaways, I strongly believe that this is a book you read once, learn a stack from and when you revisit it with more experience down the line, you'll learn even more.
Chapter 1: Welcome to Software Construction
Construction refers to the process of building. The construction process might include some aspects of planning, designing, and checking your work, but mostly “construction” refers to the hands-on part of creating something.
Software Construction mainly includes; Requirements development, Planning, Software architecture/high-level design, Detailed design, Coding and debugging, Unit testing, Integration testing, System testing and Corrective maintenance.
So why is construction/programming an important focus?
- Firstly, construction is a large part of software development – coding typically takes 30 to 80 per cent of the total time spent on a project.
- Steve also adds that programming is the central activity in software development where other tasks largely occur before or after the construction phase.
- With a focus on construction, the individual programmer’s productivity can improve enormously. Lastly, construction’s product, the source code, is often the only accurate description of the software.
Chapter 2: Metaphors for a Richer Understanding of Software Development
A metaphor serves more as a heuristic than it does as an algorithm. An algorithm is a set of well-defined instructions for carrying out a particular task while a heuristic is a technique that helps you look for an answer.
The main difference is that an algorithm gives you the instructions directly while a heuristic tells you how to discover the instructions for yourself, or at least where to look for them.
1 Penmanship: Writing Code
Developing a program is likened to writing a letter whereas writing is a one-person thing, software projects most likely involve a lot of people. In writing, a high premium is placed on originality whereas in software construction trying to create trull original work is less effective. Nonetheless, none of these associations translates well to the software development process.
2 Construction: Building Software
Here is a list of some similarities between building construction and software development:
- Size of the project increases the amount of planning needed.
- Foundation and framework come first.
- One doesn't need to recreate things that are already built. In software, eg. prebuilt libraries.
Chapter 3:Measure Twice, Cut Once: Upstream Prerequisites
No matter what the project, the preparation is tailored to the project’s specific needs and done conscientiously before construction begins.
This chapter describes the work that must be done to prepare for software construction.
The carpenter’s saying, “Measure twice, cut once” is highly relevant to the construction part of software development, which can account for as much as 65 per cent of the total project costs. 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.
The overarching goal of preparation is risk reduction: a good project planner clears major risks out of the way as early as possible so that the bulk of the project can proceed as smoothly as possible.
By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans.
Causes of Incomplete Preparation
- A common cause of incomplete preparation is that the developers who are assigned to work on the upstream activities do not have the expertise to carry out their assignments.
- Moreover, the skills needed to plan a project, create a compelling business case, develop comprehensive and accurate requirements, and create high-quality architectures are far from trivial, but most developers have not received training in how to perform these activities.
- A final reason that programmers don’t prepare is that managers are notoriously unsympathetic to programmers who spend time on construction prerequisites.
Software development is more than coding.
Studies over the last 25 years have proven conclusively that it pays to do things right the first time. Unnecessary changes are expensive.
One of the key ideas in effective programming is that preparation is important. It makes sense that before you start working on a big project, you should plan the project.
Architecture Prerequisite: Typical Architecture Components include;
Program Organization
Without such an overview, you’ll have a hard time building a coherent picture from a thousand details or even a dozen individual classes. The architecture should define the major building blocks in a program. Depending on the size of the program, each building block might be a single class or it might be a subsystem consisting of many classes.
Major Classes
The architecture should specify the major classes to be used. It should identify the responsibilities of each major class and how the class will interact with other classes.
Data Design
The architecture should describe the major files and table designs to be used. It should describe alternatives that were considered and justify the choices that were made.
Resource Management
The architecture should describe a plan for managing scarce resources such as database connections, threads, and handles.
Security
The architecture should describe the approach to design-level and code-level security. If a threat model has not previously been built, it should be built at architecture time.
Scalability
Scalability is the ability of a system to grow to meet future demands.
Interoperability
If the system is expected to share data or resources with other software or hardware, the architecture should describe how that will be accomplished.
Chapter 4: Key Construction Decisions
My key takeaways in this chapter are;
- Every programming language has strengths and weaknesses. Be aware of the specific strengths and weaknesses of the language you’re using.
- Establish programming conventions before you begin programming. It’s nearly impossible to change code to match them later.
- More construction practices exist than you can use on any single project. Consciously choose the practices that are best suited to your project.
- Ask yourself whether the programming practices you’re using are a response to the programming language you’re using or controlled by it. Remember to program into the language, rather than programming in it.
- Your position on the technology wave determines what approaches will be effective— or even possible. Identify where you are on the technology wave, and adjust your plans and expectations accordingly.
In the second part of this seven-part book series, I will dive in the next chapters of the book fully.
Top comments (0)