Built on code

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).

Securing your personal data.

A few weeks ago, a friend of mine, on returning home from work, found that her house was broken into. Her Macbook Pro, iMac, camcorder, and a digital camera were stolen. The robbery happened mid-day, in broad daylight!!!

Most of her personal digital assets, pictures and videos, stored on the computers were lost, forever. This is far more devastating than the financial impact of the robbery.

This incident got me thinking about the precautions I have taken in case something like this were to happen to me.

For about a year now, I have been regularly backing up and encrypting all my files. This in itself is not enough though, a copy of the backup has to be stored offsite. If you are in India, you can go down to your bank and get yourself a locker and store it there.

My GMail account contains in it a lot of personal information as well as credentials to other online sevices. It would be a pretty big blow if anyone were to break into my account and take control of it.

Sometime back Google introduced the two-factor authentication scheme for GMail. I felt that it was too much of a hassle to have it turned on, but this story in The Atlantic had me thinking really hard about how devastated I’d be if this were to happen to me.

As of last week, my GMail account has two-factor authentication turned on. Even though this does not guarantee security (nothing does) it does make it incredibly hard for anyone to gain control of it.

I’ve always advocated backing up files, encrypting, and storing a copy offsite. It has never been easier to do all of these without much hassle. All OSes have built in back up facilities, TrueCrypt is free and easy to use, external storage drives are dirt cheap. 

So what are you waiting for? Backup and encrypt everything!!!

Engaged

I got engaged on April 15th in Bangalore.

I had dreaded the part where my soon-to-be-bride and I had to go up on stage (with 300 pairs of eyes on us) and stand there shaking hands, greeting people who were kind enough to pay us a visit.

Much to the surprise of those who know me I was able to overcome my usual introverted, anti-social tendencies.

I surprised myself on how I handled all the attention.  To be honest, after the first 15 minutes, I realized that I actually like being the center of ALL attention :D

My soon-to-be-bride was her usual cheerful, happy, composed self.

Now that I’ve been engaged a whole week, I am now fully qualified to preach the benefits of having that special someone in your life to all my single friends.