De-Mystifying Programming

Sometimes last year I wrote a kind’a controversial post about how difficult programming is. It generates quite a lot of ruckus in the comments. Well see this as an opposite view of that post.

One thing is clear though, I still maintain that programming can not be learnt in 24 hours. I also still maintain that just as prescribing aspirin for headache (and it works) doesn’t make me a medical doctor, writing hello world (or programs in that line) doesn’t make you a programmer.

To start demystifying programming, we need to start from the basics. The first question we need to answer is this: What is a computer. I’ll give what I consider the most basic of definitions here. A computer is an ELECTRONIC device, that can take data (INPUT), perform some actions on the data (PROCESS), save the data and the result of the PROCESSing the data if necessary (STORAGE) and gives a meaningful result (OUTPUT). From my definition above I could say COMPUTER = INPUT + PROCESS + STORAGE + OUTPUT.

Programming is a kind of HOW to get the computer to behave as described above. Since the computer is an electronic device, it operates on a binary logic. ON or OFF, TRUE or FALSE, 1 or 0, etc. So to make the computer do those stuffs above we need to find a way to tell it in binary. This gives birth to the first programming languages. Programmers have to string together a whole lotto 1s and 0s to make the computer do simple tasks. We have evolved since then. These days we now have compilers and interpreters that allows us to speak more human-readable language to the computer, they then helps to convert the human readable language to something that the computer can understand.

Every program you write, even the most complex will have at least one of INPUT, PROCESS, STORAGE or OUTPUT. Take a sample code that adds two arbitrary numbers a and b to give you a third number c

INPUT = a, b

PROCESS = + (addition)


c = a + b

Here the process is a simple addition. In some cases the process might be computing the age of a dinosaur based on some bone samples found in Alaska. The concept remains the same.

INPUT = bone sample

PROCESS = compute age of dinosaur

STORAGE = save bone sample for future use

OUTPUT = age of dinosaur

And that is all. Programming is all about those four things.


1 Comment »

  1. Jason said

    Meh. That’s the way I approach programming. Start with the general questions of “What? (INPUT, STORAGE, OUTPUT) and How? (PROCESSING).” Drill down into the details and modify I/O, Storage and Processing as needed.

    In my experience the toughest part is ensuring that during analysis the WHAT’s are properly defined: (What do we get for inputs for the bone sample (INPUT)? What format is the bone analysis data stored in (STORAGE)? What is communicated to the user (OUTPUT)?”) and the HOWs (“How do we compute the age of the dinosaur (PROCESSING)?”)

    During analysis, in particular when determining how best to implement the processing, we may find out initial information/assumptions about what is needed for the INPUT or OUTPUT changes based on HOW something is processed. Additionally requirements may change as we get further along in analysis and/or implementation.

    For example:
    At the start only bone sample sample origin, sample id#, analysis method used, and age were specified for the initial report (OUTPUT).

    Later, a new requirement requests a report that contains: sample origin, sample id#, analysis method used, the number iterations run on the sample, and intermediate values for computation for each iteration, the individual results of each iteration of bone-age analysis as well as the final conclusion stated as a range, not a single value. Additionally the report is to have configurable headers, have appealing font choices and a standard footer.

    If the initial implementation has begun, this will cause a lot of work to be reevaluated, and in the worst case, most of it will be thrown away. In the best case, a new report is added as the developers and designers had enough foresight to understand the potential need for a detailed report as well as choosing to use a third party, or writing their own, highly flexible reporting engine.

    Reality usually falls somewhere in between the best case and worst case.

    So my conclusions are:
    1) When the programmer fully understands ALL of the details necessary to implement a feature/program, using a well known and well trusted tool-set and no requirements change: the act of typing in text to tell a computer what to do for I/O, Storage and Processing is very simple.

    2) However, the process of dealing with indirect coding issues is hard. These issues include incomplete information, changing requirements, complex interactions for both code level components and people involved in the process of specification, design and implementation. This makes building a flexible, yet easy to maintain application difficult.

    3) Items directly related to coding and design which occur often enough and may stymie implementation efforts are: Learning curves for large component libraries, flaws in reusable components (third party or home grown), new language semantics and syntax.

    4) Dealing with the indirect coding issues in a graceful manner is the area where many programmers can stand to beef up their skills. While experience and adequate preparation may help offset the impact of direct coding issues, these too will complicate the implementation process.

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: