First, I will briefly describe all the main sections of the book with my small comments. After that, I will write an overall conclusion with the advantages and disadvantages of the book. Spoiler: the book is very good, and its advantages far outweigh the disadvantages.
Software Development Basics
This part of the book is entirely dedicated to the basic concepts of programming and what parts make up programming and what exactly software development includes. It covers stages such as requirements definition, development, testing, and maintenance. Of course, they are described in more detail and interestingly, so it will not be boring to read. However, this section will primarily be useful for those who are just starting their career path as a programmer. To better understand this part, the chapters use metaphors and analogies (e.g., construction analogies). As in many similar books, it also mentions the cost of errors at various stages of software creation (superficially for now, as this will be covered in more detail later). Another plus of this section is that it already mentions that development approaches can be different: iterative (spiral) and waterfall. The advantages and disadvantages of each approach are briefly described. Modern and trendy terms and approaches like Scrum or Agile are not discussed here, but even the methodologies mentioned by the author are quite enough for a beginner. Finally, the author touches on important characteristics that software should have, such as: scalability, maintainability, portability, fault tolerance, security, and others.
High-Quality Code
If you think that after quite a bit of, but at the same time interesting material, you will immediately dive into a section on writing cool code and discussing hot topics like naming functions, variables, using tabs and spaces, you are mistaken. Next comes an entire section on software design. I wouldn’t say that it directly deals with full-fledged architecture — like onion (if, for example, we consider monoliths) or microservices. Rather, it focuses on describing the system as a whole, identifying some large modules within this system, and then designing individual classes, and then classes are described as separate methods. This is a kind of abstract programming using diagrams and flowcharts. I can’t vouch that this approach (with flowcharts and diagrams) is still universally used. The only place where I actively encountered this was college and then university. At no job have I drawn flowcharts, and neither have my friends and colleagues. This section also leans towards OOP, and for cases of functional programming, everything may not be so simple and obvious. So, it’s interesting to get acquainted with this section, but whether it’s worth applying it in practice is a big question.
This is more about solving small and medium-sized tasks than full-fledged projects. No mention of technologies, widespread use of abstractions, and adherence to SOLID. By the way, the OOP approach itself is quite well explained. Of course, you could read a separate book for that, but for beginners, this is enough. Much time is also devoted to good and proper naming of classes and methods. It discusses reasons when you generally need to create separate methods and when not. A few words about exceptions and error handling. Another interesting plus of the book for beginners is programming using pseudocode. I also like to call it programming on paper. It will be especially useful for beginners if they don’t know how to fully write this or that algorithm.
Variables
Starting from this section, I would recommend reading the book more carefully to all programmers, even those who have already written more than one project and have been in development for several years.
One hundred pages of material. It would seem, what is there to discuss about working with variables? There is a lot, and even much useful stuff. The section begins with an interesting test on knowledge of data types (including trees, heaps, and other types). Examples of good and bad variable initialization in different languages are given. Scopes are discussed using clear images. General tips for minimizing scope are listed.
The topic of data lifetime, naming temporary variables, statuses (flags), and naming conventions for different languages is covered. Appropriate and commonly accepted abbreviations, standard prefixes, and smart name shortening are discussed.
At the end of the section, there is a more detailed introduction to data types and their limitations: floating-point numbers, enums, constants, custom data types, arrays, structures, pointers.
Operators
This part of the book discusses sequential code organization, using conditionals and loops. The section is also 100 pages long, so there is plenty to stop at. For example, there is a detailed comparison of how the same loops are built and perform (in terms of time and duration) in different languages: C, C++, C#, Java, and Visual Basic. Topics like recursion and goto are also covered.
Code Refinement
This section consists of the following chapters:
- Software Quality
- Collaborative Construction
- Developer Testing
- Debugging
- Refactoring
- Code Optimization Strategies
- Code Optimization Techniques
It starts again with software requirements and characteristics — almost the same as at the beginning. It mentions the cost of finding and fixing defects. The section is mostly theoretical, with little code. Pair programming is mentioned. As I wrote earlier in the description of the first section, the material, including this section, is slightly controversial, as much of it is outdated. Testing is mentioned. By the way, I will soon have a review of a separate book about testing. But unlike regular books that teach what types of tests exist, what to cover, and how to write, here the author takes a different approach. For example, he describes typical mistakes in testing, such as boundary value analysis. He talks about coverage monitors (which existed even then), mentions testing tools, TDD, and some commonly accepted standards.
But the more interesting part in this section starts with the chapter on refactoring. Another example of a for loop in tests in different languages shows how differently the same construction works and consumes resources depending on the programming language. The compiler type also plays a big role. There is an interesting table showing the relative performance of code written in different languages. To comparisons of code in C, C++, C#, Java, and Visual Basic, PHP and Python are also added. You can especially often see the relative performance of common operations in C++ and Java. It’s hard to say how relevant these tests are now, as new versions of compilers have been released, new constructs appear in languages, and even interpreters, like PHP, are rewritten and optimized with each version. But the point of this chapter was not to compare the time taken for a specific algorithm or basic function (like finding a square root), but to show that the same code (function) in different languages may work completely differently (somewhere longer, somewhere faster).
At the end of the section, there is an example of how changing data types to more appropriate ones can affect the speed of algorithm execution (again, with examples in different languages).
System Topics
This section consists of the following chapters:
- How Program Size Affects Construction
- Managing Construction
- Integration
- Programming Tools
What’s interesting here? For example, the author raises the topic of how team size can affect efficiency and lists the approximate share of code written by programmers depending on the team size. It discusses how the project size, measured in lines of code, roughly correlates with error density. The graphs and tables may seem a bit debatable, but it's definitely worth reading. I would especially recommend this section to project managers.
Overall, this section is theoretical, and there is almost no code. The topic of changing requirements during the project is also mentioned, as well as how much this can shift deadlines. Additionally, the main factors related to programmers and teams that can influence speed are listed. According to the author, these include:
- the programmer's experience and skills;
- team motivation;
- quality of management;
- amount of reused code;
- staff turnover;
- requirement volatility;
- and others.
The section touches on communication with programmers and how they spend their time — meaning that even then, burnout was a relevant topic. Another topic mentioned is the so-called "religious" debates in the industry: IDE choice, naming conventions, coding styles, use of linters, and so on.
Integration is also discussed — phased, incremental, T-shaped, and other approaches. Their advantages and disadvantages are described. However, the material is somewhat outdated, as there is no mention of modern CI/CD practices.
Mastery of Programming
In conclusion, this is a general section of the book that includes many others and refers back to previously covered material. General advice is clarified here, and there are many code examples — from placing comments to working with classes and methods. I wouldn’t say this section should be seen as a summary of the whole book — rather, it's a complement to the earlier sections. The section ends with moral guidance from the author, such as attitudes toward laziness, neatness, and other personal qualities. At the end, there is an extensive list of references, which at the very least shows the professional approach and thorough research put into writing the book.
Conclusion
This book is nearly 900 pages long, but don’t let that scare you — in my opinion, the material presented here is even significantly better than Robert Martin's. Let’s list the main pros and cons of the book.
Cons:
- The book is huge, and not everyone can manage to read something of this scale.
- The publication date is not the freshest, so some examples and topics might be outdated. For example, there are no mentions of some modern programming languages, and the current approaches to app deployment and software development have changed a lot.
Pros:
- Excellent and clear structure.
- Easy to read.
- Each chapter ends with a brief summary of the key points.
- Frequent examples of bad code followed by improvements into good code.
- Code is presented in different languages, plus there are algorithm comparisons across languages.
This book is definitely a good one. I’d say it’s one of the best theoretical programming books, recommended for both beginners and experienced developers.
