I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

I read the book way back in 2011, took notes and wrote them down in my notebook, as I usually do:

In this notebook, I have several book notes, and the best of all of them landed on the inner pages of the covers:

Wishful thinking: one day this will be worth ???

Now, I figured I should get these good passages and quotes and my observations out to the blog for easier search in the future.

Too bad the actual books don’t come with a search functionality, right? ? Well, just get a Kindle, right? Honestly, I did and it seems like I still prefer ‘real’ books.

Anyways, in this post we’ll cover the whole Part 1: Laying the Foundation which consists of 4 chapters:

• Welcome to Software Construction
• Metaphors for a Richer Understanding of Software Development
• Measure Twice, Cut Once: Upstream Prerequisites
• Key Construction Decisions

The post which covers the chapter 5. Design in Construction is here.

So, let’s get to it, shall we?

Chapter 1: Welcome to Software Construction

Software construction is the central activity in software development. Construction is the only activity that’s guaranteed to happen on every project. The main activities in construction are

• detailed design
• coding and debugging
• integration and
• developer testing (unit testing and integration testing)

The quality of the construction substantially affects the quality of the software.

Chapter 2: Metaphors for a Richer Understanding of Software Development

An algorithm is a set of well-defined instructions for carrying out a particular task. On the other hand, a heuristic is a technique that helps you look for an answer. Its results are subject to change because a heuristic tells you only how to look, not what to find. Metaphors are heuristics, not algorithms. As such, they tend to be a little sloppy.

Treating software construction as similar to building construction suggests that careful preparation is needed and illuminates the difference between large and small projects.

From perspective of planning it’s not the same to build a doghouse or a skyscraper.

Also, a good metaphor for software construction is an oyster forming a pearl. The image is a good way to visualize incremental development or gradual change.

Thinking of software-development practices as tools in an intellectual toolbox suggests further that every programmer has many tools and that no single tool is right for every job. Choosing the right tool for each problem is one key to being an effective programmer.

Chapter 3: Measure Twice, Cut Once: Upstream Prerequisites

Be sure your preparation activities are reducing risks, not increasing them. If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. Attention to quality at the beginning has a greater influence on product quality than attention at the end. In general, the principle is to find an error as close as possible to the time at which it was introduced. The longer the defect stays in the software “food chain”, the more damage it causes further down the chain.

The overarching goal of preparing for construction is risk reduction.

Iterative approaches tend to reduce the impact of inadequate upstream work, but they don’t eliminate it. You might choose a more sequential (up-front) approach when:

• requirements are fairly stable
• little project risks
• long-term predictability is important
• The cost of changing requirements, design, and code downstream is likely to be high

You might choose a more iterative (as you go) approach when:

• requirements are not well understood
• the design is complex, challenging, or both
• the development team is unfamiliar with the applications area
• the project contains a lot of risks
• long-term predictability is not important
• the cost of changing requirements, design, and code downstream is likely to be low

Part of the programming job is to educate bosses and coworkers about the software-development process, including the importance of adequate preparation before programming begins.

Problem-Definition Prerequisite – the penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don’t solve the right problem.

The 25% change in requirements results in 70-80% of reworking on the project.

Make sure everyone knows the cost of requirements change.

Requirements Prerequisite – requirements describe in detail what a software system is supposed to do, and they are the first step toward a solution. Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement.

Stable requirements are the holy grail of the software development.

Architecture Prerequisite – Architecture is also known as system architecture, high-level design, and top-level design. The architecture should define the major building block in a program. Every feature listed in the requirement should be covered by at least one building block. Building block should have one area of responsibility, and the minimization of the information that blocks have about each other is needed. Architecture should specify major classes that are used.

It’s good to stick to the 80/20 rule, which specifies the 20% of the classes that make 80% of the system’s behavior.

Esential problem with large systems is maintaining their conceptual integrity.

Typical architectural components are:

• program organization
• specification of major classes
• data design
• business rules
• user interface design
• resource management
• security
• performance
• scalability
• interoperability
• internationalization/localization (I18N – Internationalization and L10N – localization)
• error processing.

The architecture should address all requirements without gold-plating (without containing elements that are not required).

I wonder when managers will start to understand that software development is more than just coding.

WISCA – Why isn’t Sam coding anything?
WIMP – Why isn’t Mary programming?

If you can’t explain something to a six-year-old, you really don’t understand it yourself.

The worst thing that can happen to you is to end up maintaining someone’s code who obviously never heard of classes, cause then you will feel like watching a foreign movie with no subtitles.

Only one subsystem/class should access database

The new design has to be easy to change without affecting business rules and program results.

The architecture should clearly describe a strategy for handling changes.

We’ve always done it that way – be wary of that statement! To this, I’d add “Do your best in trying to inform, but if management doesn’t budge, run away as fast as you can”

Bad requirements – if they are found out later, the fixing costs a lot more.

Chapter 4: Key Construction Decisions

Use a language that you’ve used before, and you will become more experienced with it and more productive

C#, C++, Java, Visual Basic – 5 to 15 times more productive than C, Assembly

Developers working in interpreted languages are more productive than the ones using compiled ones.

Most common languages:

• Ada – named after Ada Lovelace, the first programmer; used in military, space, and avionic systems
• Assembly language – assembler, low-level language, used for maximizing speed and code size.
• C – 1970 Bell Labs
• C++ – 1980 Bjarne Stroustrup
• C# – 2001 Microsoft Anders Hejlsberg
• Cobol – Common Business Oriented Language, developed in 1959 – 1961
• Fortran – first-high level computer language
• Java – developed by Sun Microsystems; runs on virtual machine
• JavaScript – primarily used for client side programming (note by me from 2017: not anymore. Node.js made sure of that.)
• Perl – string-handling language; often used for system administration tasks.
• PHP – used to access server-side interactive functions and accessing database information. Note from me: everybody seems to hate this language nowadays ?
• Python – Python is an interpreted, interactive, object-oriented language that runs in numerous environments
• SQL – declarative language, meaning that it does not define a sequence of operations, but rather the result of some operations.
• Visual Basic – high-level, object-oriented, visual programming version of Basic developed by Microsoft.

Programmers who program ‘in’ a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer’s thoughts will be primitive.

Programmers who program ‘into’ a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Conclusion

Hope you liked this post and that you’ve seen that this book really has a lot to offer, so I urge you to get your copy, read it and apply it!

Until next time, take care and keep on improving ?

My #notes from all-time classic #book Code Complete 2 by Steve McConnell Part 1: Laying the Foundation https://t.co/8jpjxTgMql

— Nikola Brežnjak (@HitmanHR) August 1, 2017