while (true) { 
    progress++; 
    progress -= 2; 
}

O (2001)

[3.5/5]

Small update

That busy period at work that I mentioned hasn't really ended, and by the sounds of things it won't be any time soon. As such, it's likely that my Code Complete series is going to be put on hold for a while longer as we ride this current and move on.

Random Stuff:

Code Complete: Design in Construction (Part 3 - Design Building Blocks: Heuristics)

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!

[img_assist|nid=103|title=Chocolate Heuristics|desc=Copyright © 2006 maadmob|link=url|url=http://www.flickr.com/photos/maadmob/|align=center|width=400|height=330]

Code Complete: Design in Construction (Part 2 - Key Design Concepts)

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!

Key Construction Decisions

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

Superuser.com Private Beta

It was announced a few days ago that the Super User private beta has begun. Instructions on accessing it are available from the Stack Overflow blog announcement.

Code Complete: Brief Interlude

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.

Code Complete: Design in Construction (Part 1 - Design Challenges)

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.

[img_assist|nid=98|title=Design can be a wicked problem|desc=|link=none|align=center|width=400|height=292]

Code Complete: Measure Twice, Cut Once (Part 2 - Essential Prerequisites)

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!

Code Complete: Measure Twice, Cut Once (Part 1 - The Importance of Prerequisites)

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.

Pages

Subscribe to Front page feed