Code Complete: A closer examination (Chapter 5)

Chapter 5: Design in Construction

Design is the activity that links requirements to coding and debugging

What are design challenges?

Design challenges are the various problems that designers encounter when designing software.

The author continues to mention some of the design challenges which include:

1. Design is a wicked problem — a problem in which the solution has to fail so that one can learn from the failure and come up with a better solution
2. Design is a sloppy process — It is hard to know when the design is good enough
3. Design is about trade-offs and priorities — It is important to strike a balance between competing design characteristics
4. Design is non-deterministic — There are several solutions and approaches when designing software
5. Design is a heuristic process — It involves trial and error

I personally like the thrill of numbers 4 and 5 because they hugely rely on each other. The idea of having several design solutions to a problem and that all of them might lead to a solution is music to my ears.

What is software complexity and how do we attack it?

The author defines software complexity as when a software grows so big that no one knows how changes to a particular piece of code might affect other areas of code and functionality.

The author argues that in order to solve complexity, it is critical to minimize the amount of complexity and keeping accidental complexity from proliferating.

From the above, we should not come up with many quick fixes for a complex problem.

The author proceeds to explain the desirable characteristics of a design which include minimal complexity, ease of maintenance, lose coupling, and extensibility.

What are the levels of design?

The author dives deep into the various levels of design which include the software system, division into subsystems, division into classes within packages, division into data and routines within classes, and internal routine design.

All the levels are important, but the division into classes caught my eye. It is important to design classes that perform single pieces of logic in the whole system. This helps support the idea of components that support the overall design.

What are heuristics in design?

Heuristics, in this case, refer to the various ways of thinking about a design that produces better insights. Basically, they are the guides to the trials in the “trial and error” during design.

The author introduces us to the various ways of applying an effective set of heuristics when doing software design. The set of heuristics include:

1. Find real-world objects — Identifying objects, their attributes, and their relationships with other objects
2. Form consistent abstractions — You are allowed to take a simpler view of a complex concept
3. Encapsulate implementation details — You are not allowed to look at the details of the complex concept.
4. Inherit — The idea that you can open and close a door regardless of what it is made of
5. Information hiding — Hiding the inner workings of a house
6. Keep coupling loose — Making modules as independent of other modules as possible, just like the wagons on a train
7. Look for common design patterns — Most problems are similar or mutations of past problems

How do we handle change in design?

A good way according to the author is to identify the areas likely to change and isolate them.

I agree with the author because have encountered this before. A simple example from my initial predicament was when I wanted to change the name of an application depending on the environment (either test or prod). The solution was to isolate the app name into one file so that when I wanted to change it I could change it there.

What are design practices?

The author introduces us to a new set of heuristics that produce good designs. These include:

1. Iteration — Involves cycling through design attempts as you inspect their low-level and high-level views.
2. Divide and conquer — Divide the program into different areas of concern, and then tackle each of those areas individually
3. Top-Down and Bottom-Up Design Approaches — Involves starting from either generalities or specifics
4. Experimental prototyping — You can’t really come up with a problem until you have actualized it.
5. Collaborative design — Bouncing some ideas with someone else

Conclusion

The author has done a good job of explaining the design process during software construction. However, I felt like even though the design is a huge topic, the author could have simplified most of the topics a little. Regardless, I learned a lot about heuristics and how they can be used for better software design.

I am a believer in combining ideas and I am a huge fan of applying more than one heuristic in solving a problem.