The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.
Today was Day 1 of the Rest of my Life: I read the preface and first chapter of Code Complete, and here’s what it had to say. The book is aimed at four groups of people: experienced programmers, technical leads, self-taught programmers, and students. In short, this is a book for everyone. The justifications for each are as follows.
For experienced programmers, the book serves as a reference for, and reminder of, best practices in software construction (more on that term later). It reminds you that [Software Development] != [Programming]; software development is a bigger process than writing code.
For technical leads, Code Complete has real use as a mentoring aid for the education of junior developers in your team, and can help you fill your own knowledge gaps in the software construction process.
An interesting statistic quoted in the preface claims that ~50,000 new developers enter the profession each year, and only ~35,000 software-related degrees are awarded each year (I believe these figures refer to the US). Thus, there is a sizeable proportion of the total development community that don’t have software-related degrees: bankers, administrators and accountants all might have development-type aspects to their jobs. Scientists write code to model data and perform their experiments. None of these people have had formal education in how to program computers, but Code Complete can fill the gap.
The final group the book is aimed at is students. The single reason McConnell gives for this is that fresh graduates are often rich in theoretical knowledge, but poor in practical know-how (hi there!). This gap is now being addressed by courses and modules covering software engineering practices, but the reality is that this too will be theoretical knowledge with little or no hands-on experience of the concepts.
The overall aim of the book, therefore, is to be “A Practical Handbook of Software Construction”. As such, it can be tackled cover-to-cover or dipped into for a refresher on particular topics.
What is this “Software Construction” thing, anyway? McConnell likens the process of building software to the process of constructing a building of some kind. You take the plans and you design and build your individual components and assemble them into a whole. I’m not completely sure I agree with this metaphor — I’ve always felt that it was more akin to the art of writing, what with its plans and re-drafts and what-have-you — but I’m happy to run with it for now. Maybe that’s what appealed to me about the profession in the first place: software development can be viewed as a craft, like carpentry for example, and thus has elements of an artform. Well-written, elegant code can be as breath-taking and beautiful as Rodin’s The Kiss, in its own way.
| [img_assist | nid=89 | title= | desc= | link=node | align=center | width=400 | height=564] |
Anyway, I digress. McConnell includes the following processes, amongst others, in the concept of software construction:
In short, software construction is the end-to-end process of developing a software product. It is not, however, the full lifecycle of the product, nor even the project; note that requirements’ gathering, architecture design and maintenance/support are all out of scope.
Why is this process so important? Is it that important? Well, in a word, yes. There are many reasons for this, but fundamentally:
Construction is the central activity in software development, and the only activity that's guaranteed to be done
Let’s stop and think about this for a second. Requirements gathering, architecture design, and even testing can all be — and have all been — skipped over to get a product released to market on time. The construction, the actual building of the product, is the only activity that will be completed.
The key implication of this, and the motivation for the entire book, is that improving the process of software construction is guaranteed to improve the product quality. Even if other steps in the process are skipped out altogether, the quality of the construction determines the quality of the product. This concept applies elsewhere, as well. Look at the iPod, for example. It is market leader not because of its features or sound quality (both of which have been criticised in the past) but because it is so well constructed. The design and build quality of any of the models in the iPod range is second to none in the portable media player market.
The corollary of this idea is that your understanding of how to do construction determines how good a programmer you are. If you have a good understanding of software construction, you’re likely a very capable and professional developer; if you don’t, you’re very likely at the other end of the scale. That’s where I am, and I intend to do something about it. Will you?