Some Ideas From the Practical Handbook of Software Construction: Code Complete
Change the way you see software construction
Code Complete is a book on software engineering, written by Steve McConnell and published in 1993. Kind of old, you may say.
Maybe, but the ideas in this book are amazing and will change the way you see software construction. I would like to share some of the ideas I found revealing.
Keep in mind that the notes presented here are a minimal collection of the knowledge stored in this book. I hope that this piece will encourage new readers to try this amazing book.
Coding vs. Software Construction
Although the terms coding and software engineering are often used interchangeably, they are not quite the same.
Software construction refers to coding and debugging, but also includes design, unit testing, integration testing, and other activities described explicitly in the book.
When we say “coding”, we often refer to the mechanical action of translating a pre-existing design to a computer language. Therefore there are coders and software engineers.
You may have had a programming professor that took away lots of points on your programming assignment if the assignment wasn’t properly documented.
You didn’t like that, did you? I understand. But think about it. The product of construction, the source code, is often the only documentation available to the programmers, thus, it is imperative that the source code has the highest quality possible.
When you write code, think about your audience and your fellow programmers, who one day will have to maintain that codebase. Make their life easier.
The most challenging part of programming is conceptualizing a problem.
Metaphors often provide helpful insights to see the problem from different angles. The ability to approach problems is more valuable than knowing specific solutions.
How do you develop this skill? You program.
I started a quest to solve at least one programming challenge every day for an indefinite amount of time. I will talk more about this in the future. It is based on the idea of compound improvement, described in this article.
Quality Assurance Is Not Just Testing
Software quality assurance is not limited to testing. Testing cannot reveal problems that were introduced in the prerequisites development or problem definition stage.
You may have a fully functional program that solves the wrong problem due to incorrect problem definition.
You may have a program that solves the right problem but does not include all the desired functionalities due to incorrect prerequisites development.
Finally, you may be solving the right problem with the right features but just the wrong way, due to poor architectural design.
Explicit requirements prevent you from guessing what the user wants.
Tip: Have a problem definition, a clear statement of the problem the system is aiming to solve.
Important objection: Keep in mind that stable requirements are often a myth. Customers will change their requirements as the system progresses, as they will understand their own need while the project advances.
Your programming tools don’t have to determine how you think about programming. Program into the language, instead of programming in the language.
- Programming in a language: A programmer that programs in a language limit their thoughts to the constructs provided by the language. Thus, if the language is primitive, their thoughts will also be primitive.
- Programming into a language: A programmer that programs into a language will first decide what thoughts they want to express, then determine how to express these thoughts using the tools provided by the language.
These ideas are described in much more details in Code Complete. I am still digesting the book. I highly recommend it, enjoy!