Software Construction & Metaphors

This post is part 1 of a series that documents my understanding of software construction as I read through Steve McConnell’s excellent Code Complete.

I was reading up on software construction and the importance metaphors to get a deeper understanding the process of software development. What follows is my understanding of the aforementioned topics.

Software development is a set of distinct activities. Software construction, what most developers would think of as ‘coding’ or ‘programing’, is one such activity. It is important to understand how to get better at software construction as it represents a large and important part of the overall software development effort.

When building software, it is possible that other activities of software development have been skipped, but construction is the only part that is guaranteed to be done, because without that there would be no product. Also, developers vary in skill by a large factor when it comes to software construction. Focusing on how to get better at it will have a huge impact on the overall quality of the software product.

Metaphors have been used widely to understand new phenomena by relating it to something which we already know and understand. Using metaphors we can better understand the process of software development.

Metaphors in software development range from the rather simplistic – writing software (writing a letter), growing software (farming) and software accretion to something more complex and inclusive – constructing software (constructing a house).

The ‘house construction’ metaphor is the most inclusive when thinking about software development because there are a lot of similarities in both fields.

When constructing a house, the amount of upfront planning, architecture, design and construction methods will depend on the kind of house that is being built. Larger structures require more upfront planning and formal methods of design at every stage. This is similar to software development where a large software project consisting of hundreds of modules and external interfaces will have to go through a much more formal design and construction process. This is in direct contrast to building something simple; say a bookcase, where you do not need much upfront planning at all.

Though McConnell’s ‘building a house’ metaphor best explains the software development process, it too is lacking in some aspects. Software requirements are much more subtle and prone to changes than say requirements that are given when building a house.  Once a house is built, it tends to remain in its original form for years or even decades, but in isn’t the case when it comes to software.

When it comes to constructing a house, you can plan activities to be done one after another (waterfall model) and some of them can occur concurrently. When each activity is completed and verified, you can move on to the next stage without having to worry about any changes in the activities preceding it. For example, when the land has been dug to lay a foundation that has been verified to be stable and secure, you can move on to building a house on top of it. In software construction, there are changes that come about constantly to the basic foundations that were taken for granted at the beginning of development but which are later questioned and can be changed. These changes can be to the underlying technologies on which the foundation was built or to the requirements that were not correctly stated or were misinterpreted.

I guess this disconnect comes about due to the nature of the two activities, construction of a house and constructing software. Software is a representation of your ideas on how to solve a problem. The raw materials in case of software development are ideas, which are a lot more subtle and prone to change than the materials used to build a house.

Until we find something better that reflects this subtlety, the ‘house construction’ metaphor should suffice when thinking of software construction.

The ‘software penmanship’ metaphor along with ‘software accretion’ a.k.a iterative development is somewhat apt when it comes to building software using a dynamic language. A dynamic interpreted language give you the ability to figure out the program as you write it (mostly because the availability of a REPL and duck typing).