Code Complete: A Practical Handbook of Software Construction, Second Edition
Essential reading for all software developers
Why I Read this book
If there is one book that has been a constant desktop companion for the most part of my software development career it’s , after I initially purchased this book back in 2006. It’s value to my career is not to be under estimated!
Although I would be the first to admit, I have never read this book cover to cover in one sitting, to be honest it’s just not that type of book! It’s pretty long book, over 800 pages! That being said I have read this book over and over again, chapters and sections at a time. Often refering to it for inspiration, understanding and often solutions to problems.
One of the greatest values of this book, is that it acts as reference to many great software development books, authors and articles, which also make interesting reading and for the most part essential if you’re interested in further perfecting your craft and profession in software engineering. Giving the reader plenty of resources to further their discipline. Irrespective of programming language and platform.
What I liked about this book
The first part of the book is dedicated to laying the foundations for all software development projects. Providing tips, strategies and discussions for all the things software developers should do before putting hands and keyboards and churn out code.
- Problem Definition
- Requirements development
- Development Planning
- Software Architecture
- Detailed Design
- Unit Testing
- Integration Testing
- System Testing
- Corrective Maintenance
A lot of these concepts, have been lost in translation as many organisations have attempted to move to being “Agile” and decree that anything which seems to resemble anything that is “Waterfall” thinking to be old hat and irrelevant. However this books serves as a contradiction to those points.
If your project is properly defined before you start coding, then coding simply becomes a formality, there shouldn’t be any surprises. But if your requirements or the architecture you selected is wrong, it will be expensive to fix it later in the project. The later the error is noticed, the more expensive it is to fix, if an error is noticed when the project is finished/released it might cost you up to a 1000 times more to fix it then if the error was noticed during the initial stages of the project.
These are simple notions, which are all too often ignored or neglected in the name of “Agile” and all dogma associated with it. In fact, most software teams could do with reading Chapter 28 – Managing Construction, and the additional resources it provides!
What I learned from this book
The second part of the book is looaded with great practical advice which includes software design is about managing complexity, and everything we do should be as simple as possible.
Steve McConnell discusses iterative design, which is an interesting concept. You evolve your design with your project, and the more possibilities you try, the better the final design will be. As you can see this kinda fits with the agile methodology of software development.
In chapter 6 you can learn how to create a good class. It’s tempting to just subclass a class, and keep the shared code in the super class, but this will eventually complicate your class hierarchy.
They say that a human mind can, on average, hold 7 individual pieces of information, so it’s good if you follow the single responsibility principle, and if you favour composition over inheritance. So as you can tell the book also discusses the foundations of SOLID Principles, without actually ever refering to them,
The whole of part 3 is dedicated to Variables! Which is worth reading.
We all know that one of the hardest things in software development is naming variables, So naming conventions are a good thing to have. We read a lot more code than we write, so having good variable names is very important.
My personal favourite part of is part five, which discusses code improvements.
It plenty of useful information and tips on to improve the code quality, from code reviews and testing plans to following common guidelines.
It might be a bit slower to develop software with all these mechanisms in place, but fixing nasty bugs in the production would definitely be more expensive. One of the ways of improving quality is collaborative construction : (code reviews, pair programming, walkthroughs)
Choosing what works best for your project, maybe even choose multiple things. And, of course, testing is a way to improve the quality of your code. If you realise you made a mistake designing a class you can always refactor it, you can find some specific useful advice on ways to refactor your code.
Why I recommend this book
There are not many books in software development that reamin timeless, but this book is one of them for sure. It and the numerous references it contains make great reading for software developers of all levels.
A unique background as business owner, marketing, software development and business development ensures that he can offer the optimum business consultancy services across a wide spectrum of business challenges.
Latest posts by Gary Woodfine (see all)
- The Builder Pattern .net core - May 1, 2019
- Book Review: The Lean Startup - April 28, 2019
- Using Serverless Framework Environment Variables .net core Lambda - April 25, 2019