Development of the technologies, functionality, features and value proposition is fundamental to the sucess of any product within the InfoTech market place. Although Pre-Sales rarely delve deeper than the occasional script, it’s worth having an understanding of what’s going on under the bonnet of your products and solutions.
In this blog we’ll chronologically examine a brief history of the development of programming. I’ll be writing this with-out reems of reference books around the desk, so please take the dates, claims and details as generally correct (this blog is not written to be used as a reference). There are hundreds of different languages out there, most of which aren’t covered here. It’s purpose is to give you a general idea of how your developers are creating the functionality that you are ultimately trying to sell.
Before we start, I’ll pay quick homage to Charles Babbage. He’s pretty much the Grandfather of modern computing and you can read about him by clicking his name above.
Ok, Let’s start.
I’m going to start with Binary.. yes, binary. I remember when I was around 10 years old. I bought a computer game magazine which had in bold letters on the cover.. “Write your own game!”. After asking my dear old Mum to buy the mag. I started reading and realized that the mechanism for writing the game was to literally write the binary 0’s and 1’s into a text file which would later be run as the game. After several hours of type 1010110110101001010010010110101, my long suffering Mother stepped in with her superior typing skills and finished the job. Unfortunately, it didn’t work. Somewhere amongst those 1000’s of 0’s and 1’s there was a mistake. Were we going to go back and check each one? I think not. This was my first ever failed attempt at coding. You’ll see as we continue that the development of code has somewhat improved since then.
Assembly was one of the first primitive languages to be created to allow developers to create code. The language primarily consisted of 3 letter acronyms (e.g ADD, MOV, RTN, STA) which gave the direct control over computer memory locations and allowed calculations to be performed through the CPU with the use of an entity called the accumulator. You can find an example here.
In earlier versions of systems from the Unix family, Assembly was used as the core programming language for the operating system. This was later replaced by C as the evolution of Unix progressed.
Procedural Code – For Example – C
C was originally developed by Dennis Ritchie of Bell Labs in 1972. It was created as a systems programming language with a goal of simplifying and making the process of system software installation more portable. In C, software packages are developed, compiled and added to the library of code available to the system where it’s installed.
C is a procedural programming language. Being “procedural” in nature means that it is generally written in a linear fashion. Batches of logic can be grouped together into functions, which are reusable blocks of code, but procedural code is notorious difficult to maintain, extend and debug.
Enter Object Orientated Programming (Java, C++ and more)
In the 1980’s, C became C++. C++ built on the foundation of the systems programming language C. It introduced Object Orientated concepts to coding. Object Orientated programs try to model real-world objects and abstracts directly into the code. What this essetially means is that if our program is related to dogs, we can create a dog as an object in the program. This object may have many attributes, such as colour, height, breed. If we want to do something with the dog we have to invoke a “method” (in procedural terms this would be a function). An example of a method may be “walk the dog”. By walking the dog we may change some of the attributes of the dog, e.g. location.
You may ask, why would we go to all this bother?. Well, the great thing about objects is that they’re reusable. We can create a blueprint for one (referred to as a class) and create as many dogs from that blueprint as we like. Additionally, if we have a slightly different type of dog, perhaps a different breed, we can use the same blueprint, but extend it slightly for the new object, this is called inheritance.
Another great benefit of “encapsulating” these objects into their own seperate spaces is modularity. A program should never change an attribute of an object directly, interaction with objects should be done through methods. This means that we can isolate the logic related to an object. So, when we change the logic or code for an object, it should not affect the other objects in the program. Now, imagine 100 developers working on a program. How difficult would that be with procedural code? The answer is very.
What you tend to find is that there is more overhead for OO in the beginning, but once a library of objects is built up, it becomes a very fast process to create new code and functionality.
Libraries, Frameworks and IDEs
As languages have matured over many years, developers have made their own code freely available to others. After all, why start from scratch when you can download and use someone elses hardwork as a base. I believe the term is “Standing on the shoulders of giants”. Libraries are pre-packaged batches of objects and procedures. Depending on the language being used there are usually thousands of pre-developed snippets of code available for use.
A framework takes this a step further. A framework will not only make pre-built modules of code available to developers, but they can also provide a structure for an application. This is where an Integrated Development environment(IDE) comes in handy. IDEs usually provide a graphical interface which helps to implement the structure and model of an application. The structure and model will guide the developer on where files are stored, how to segment different types of logic and in some cases also provide functions to assist in the testing of the code.
Key topics to understand here are the differences between Procedural and Object-Orientated code. You can see through the evolution of programming how different coding is today from when it started those many years ago. Although for Pre-Sales it’s a very rare occurence to even see the code of your application, you may however be in regular contact with the developers to discuss new features and requirements. Having an understanding of their environment can give you confidence that you truly understand what’s going on in the heart of your offering.
One warning worth taking on board is that you shouldn’t get too pre-occupied with the bits and bytes of the code. That’s the developer’s responsibility and if you slip too far in that direction you may find yourself wearing shorts, white socks and sandles to the office. You may also find that you’ve developed new and interesting social quirks that you never knew existed.
Thank you for reading.