Code Complete

This post represents the second instalment taken from chapter 6 of Code Complete, entitled "Working Classes". This post covers the issues to consider when designing class interfaces, illustrated with code samples. An important piece of information to keep in mind when reading this post is that McConnell is talking in terms of the public interface exposed by a class through its public members. While an interface (as defined in Java or C#) also fits this bill, some of the advice given here is specific to the idea of a class interface, and not a standalone interface.

If you're after the executive summary (this is quite a long post, after all), there are only two things you must build into your class interfaces: good abstraction and good encapsulation. Read on to find out more.

Another day, another Code Complete blog post. I might even clear two today, looking at the number of notes I have for this one.

The last post rounded off the contribution to the discussion around the problems of designing software. A new chapter means a new topic, and chapter 6, titled "Working Classes", deals with tips on, and the issues around, creating classes in your program. First up is the topic of Abstract Data Types: what they are, why you should be interested, and how you should use them.

Wow, it's been quite a while since I updated my Code Complete series, and I've got quite the backlog to wade through now! Looking at the last save date on this post, it's been sat around for three months waiting to be written, so I'm sorry for being so slack, and I'll get on with writing it now...

This post covers some key design practices, and is the last post on Chapter 5, Design in Construction.

Ok, so this is my first post on Code Complete for a little while; it turned out the busy period at work lasted a good couple of weeks longer than I thought it would! It was a quite a while back that I made these notes (mid-June, in fact), so if the post seems less coherent or I've got something obviously wrong, please leave a comment. Here be dragons.

This post deals with design heuristics. We've already touched on what heuristics are in the Software Development Metaphors post, so you might want to refresh your understanding before reading on. Inside, I will cover McConnell's description and critical evaluation of the most common design heuristics. These can be viewed as smaller steps in a larger process, or as individual methods to use at different stages of the design process.

Note: this is a long post!

Chocolate Heuristics: Copyright © 2006 maadmob

Design is essentially an exercise in managing complexity, and it is incredibly important to manage correctly. Dijkstra (1989) stated that a single person working on a software development project needs to grapple with anything from one bit to a few hundred megabytes: this is 9 orders of magnitude. Given that software is always increasing in complexity, McConnell posits that this figure could be as much as 15 orders of magnitude or more today.

This post covers in some depth the issues around managing complexity, ways to attach it, and the importance of doing so. It will also cover desirable characteristics of design, and the different levels of design.

Note: this is a long post!

This is a relatively short post, covering the key construction decisions Steve McConnell highlights in his book Code Complete.

I have a couple of new posts waiting in the wings for this series. They're both quite lengthy, so they're taking a bit of time to write.

Things have also got considerably busier at work in the last week or so, and it's proving nigh on impossible to dedicate the time to reading and absorbing the material. As such, there will likely be a bit of a gap in my postings on this series after I've cleared out the back-log.

If you've been enjoying the series so far, and/or if you have any feedback on how to improve it, etc., please leave me a comment or two.

Chapter 5 of Code Complete covers the concept of Design in software construction. This is a pretty weighty chapter, so I'm going to tackle it in a mini-series of posts. Here I cover McConnell's description of the design challenges, including why it's so hard to get right.

This post is a something of a bite-size chunk, and hopefully it'll provide a measure of breathing space between two large posts.

Design can be a wicked problem

Part 1 of this post covered the importance of pre-requisites: why it is worth doing them, and doing them well; why it is a bad idea to jump straight into coding; and how to ensure that they are completed at your organisation (if they aren't automatically already).

This second post covers the three main pre-requisites, namely Problem Definition, Requirements, and Architecture.

Note: this is a long post!

Any good carpenter, joiner, or other worker of materials will tell you to "measure twice, cut once". This is a good philosophy to apply to life and your craft as a software engineer. It implies attention to detail, efficiency and proper preparation; it results in "right first time" components and products, quality and reduced waste.

So, getting your pre-requisites right is important. There are different opportunities to emphasis quality: at the beginning of the project (planning and design), during the construction of the product and at the end of the project (testing). During the construction phase, your only option is to build the product solidly, with quality materials and tools. At the end of the project, when your only option is testing, you can't detect that your product is the wrong solution for the problem, or that it is the right product built in the wrong way. Testing is only one part of quality assurance, and only ensure that the thing is fit for purpose.

Therefore, the planning and design stages are your one opportunity to "get it right", and the cheapest opportunity to resolve any issues. You can, and should, make sure you have the right project and the right plans, and ensure the design is fit for the product. It's a risk reduction process. As my Dad used to tell me, and as his boss (fittingly, in the construction industry) used to say, remember "The Seven Ps": Proper Preparation and Planning Prevents Piss-Poor Performance.