Home
Blog Tags

Learning to Design Programs

Wednesday, Apr 29, 2020
Functional Design

During the past week, I discovered something very interesting: Programs can be designed! instead of just being written. This brings in a completely new perspective for me to programming. While in general, I have heard about software design, my impression is that this term concerns with larger (enterprise level) software undertakings where everything is scaled up (number of customers, developers, products etc.). Interestingly, while you might find software design as one of the courses in a typical undergrad CS curriculum, it's hard to find a course on program design (a quick google search on my query “program design course” gave over 2 billion results, however, the first page was mostly around “software design courses” and I did not bothered to check the other couple billion pages).

What is Design?

According to webster, it is “to create, fashion, execute or construct according to a plan". So the term refers to having a plan before you start to construct something. Design is typically associated with something tangible - buildings, bridges, automobiles, homes, etc. In tangible objects, cost of having a bad (or no) design can be prohibitive enough to avoid starting without one. Software design can also be seen in the same light at the enterprise level, where chosing one technology over the other can make a difference between a successful business or no business at all.

Why is program design not common?

Well, I think there are two reasons:

  1. Low cost endeavour: When learning to write programs, a bad syntax in “hello, world!” program at first attempt would just lead to a program crash, with cryptic error(at worst) which you can likely google your way out of. The likelihood of your computer physically burning down to ashes for an error is close to zero. So we continue to hammer at it until it works. So what's the point in spending time designing a program? Unfortunately, this habit(as with any habit) is hard to break later.
  2. Fear of creativity loss: By definition, design must come before execution. Writing a program, on the contrary, is a microscopically iterative process. We cannot conceive all possible problems before trying our ideas. New ideas can be conceived when solving a problem with an older one. A frozen design before typing our first character seems like death to our creativity and problem solving nature. So again, what's the point in designing a program when you know that it will change the moment you start writing it?

So what's the point?

This leads to my discovery: How to Design Programs - a beautifally written text on the subject. I have just started reading it and it has blown my mind away. The authors (there are four) are masters of their domain and they put a convincing argument (in preface) as to why do you want to learn to design programs. Let's look at the two reasons stated earlier as why a lot of people are not interested in program design and how the text addresses them through systematic program design:

  1. Low cost endeavor: While it certainly does not cost a fortune to write your function one way or the other when you may just use it once (or twice) and forget about it, in a more interesting (and larger program), the way your function fits into the whole impacts the performance of the program (is the code still readable?, modular?, extensible?, robust?…). Thus, you want to approach your program/function writing using a common design process or design recipes.
  2. Fear of creativity loss: Through iterative refinement (second idea for successful systematic program design) one can solve the problem in stages starting with a higher level of abstraction leaving out the details in the beginning. Then details are added one by one through subsequent refinement steps.

I want to note that these ideas are not new and are discussed here and there in some form in many programming textbooks (document your code, test it, leave out the details in the beginning etc.). But none talks about how to whereas this text brings the process of program design at the focal point.

Why am I enjoying this book?

It does not read like an academic textbook, instead like a master having a conversation with you on the subject. Things I like about the book: