Have you ever wondered how it is that software programs are actually created? What is it that actually drives developers to spend numerous hours writing thousands of lines of code?
The reasons may surprise you as these two renowned developers share their real motivations in these TED Talks:
Dan Bricklin invented VisiCalc, the electronic spreadsheet that helped put Apple Computers in the business world. Watch this TED Talk (video) to discover why!
http://www.ted.com/talks/dan_bricklin_meet_the_inventor_of_the_electronic_spreadsheet?utm_source=tedcomshare&utm_medium=email&utm_campaign=tedspread
Linus Torvalds is the mind behind Linux and GIT. This TED Talk interview presents surprising insights surrounding the development of one of the world’s more popular operating systems and renowned version control management tools.
http://www.ted.com/talks/linus_torvalds_the_mind_behind_linux?utm_source=tedcomshare&utm_medium=email&utm_campaign=tedspread
These TED Talks are encouraging as they echo the story behind some of my own projects albeit on a much smaller scale.
I started learning to program PC’s in the early 1980’s when our company decided to purchase an IBM PC for the corporate engineering office. The Intel 8088 chip running at 4.77 MHz was the brain inside our office IBM PC where double side – double density 5-1/4 inch floppy disks having a capacity of 360K served as our storage medium.
Aside from DOS 1.0, our software library was comprised of three programs: Lotus 123, dBase II, and Wordstar. After reading every page of the manuals that accompanied the software and working through the examples, I was intrigued by their capabilities and even more curious to know how these programs worked.
I spent some time talking with the administrator of our corporate mainframe computer and asked what languages may have been used to write these programs. He suggested they were likely written in C, assembly language, or a combination of both.
As a recent college graduate, I couldn’t afford a C compiler and Microsoft’s MASM was surprisingly cheap relatively speaking. I decided that assembly language was going to have to be my language of choice.
I purchased the few books and magazines that were available from our local book store and started reading. The only editor I had at my disposal was “Edlin”, a command driven line editor that came as part of DOS (Microsoft’s Disk Operating System). Extremely simple “.com” programs could be written using “Debug”. Either of these programming environments made programming a rather tedious process but did not deter me from my learning adventure.
After a short while, I started working on an editor of my own. First a simple screen dump that allowed me to display – and optionally print – my code with line numbers. Over the course of many weeks and months my program blossomed into a complete file manager and full fledged editor – line numbers included – all written in assembly language. Things really got exciting when I was using my editor to write code to improve it.
Some of the nicer additions included a decimal / binary / hex / octal calculator, complete with XOR, AND, OR, and NOT operators, a cyclic redundancy check routine that provided a very quick way to determine whether the file’s contents changed, and serial file transfers between two machines to complement the other file management options – copy, move, print, and delete.
Soon pop-up windows and a “lotus style” menu / sub-menu were incorporated into what became a “sought after” editor among my peers.
All of my code was modelled using pen and paper. I recall developing my “windowing” routines while on a business trip in Paris, France. My carefully managed notebooks were filled with notes on video hardware, diagrams of memory management, “window stacks”, sound effects and an array of code snippets just waiting to be integrated into my editor.
Multi-tasking using interrupt vectors was another of my greater and more rewarding challenges. I created a routine to automatically update the date and time in the lower right hand corner of the screen. When the time wasn’t updating, a small “pulsing” graphic was updated next to the time to provide visual feedback that the routine was working. The graphic was affectionately known as the “heartbeat” of my system.
To the amazement of my peers, the time on the screen was updating every second and the “heartbeat” kept pulsing even while the computer was performing other CPU intensive tasks.
To simulate this effect, my peers were looping through a “wait key” routine and updating the time if no keys were pressed. The problem with this solution is that the time would not be updated if the user struck a key that required the program to perform an alternate task. I finally wrote a routine in assembly language that they could call from “C”. They were given the ability to call my clock routine with the location and color of the date and time message to be displayed. Another routine was created to terminate the clock when required.
I wrote interrupt vector routines for a variety of other tasks to manage printer ports, serial ports for serial communication, and keyboard interrupts for capturing unique keystroke combinations such as Ctrl-Break and Ctrl-Alt-Del.
When I developed the Cyclic Redundancy Check (CRC) routine / protocol for my serial communications module, I used pennies to simulate bits being turned on or off as a means to visualize the code being executed in the “real” world.
I incorporated the CRC check into my “Editor’s Exit / Quit” menu functionality. If the CRC value changed, the user would be prompted with a message window and the option to save the file before closing it. This validated my CRC routine for other features such as backing up files that have changed. A changed date / time on a file does not necessarily constitute a change to the data it contains.
I went to our local Radio Shack store to purchase telephone connectors and wire for my first twisted pair serial cable. When the sales person asked what I planned to do with these items, I told him I was going to connect my computers to send files from one to the other without having to use a disk. His laughter still echoes in my mind.
My serial communications module was a great success. I could scroll through the files and select the ones I wanted to send. A copy of my “Editor” on the receiving machine managed the incoming files. The CRC routine I created was incorporated into my data transfer “protocol” and ensured the files were sent and received successfully.
When one of my colleagues disconnected the cable between the two machines to see what would happen, a message instantly appeared on the screen: “Data Transfer – Unexpected Interruption. Please check the connection and press to resume or to Exit.” To his surprise, we reconnected the cable and the data transfer continued successfully.
As the number of modules continued to grow, I found myself writing a small scripting language to execute my “make file” to assemble and link my code. My script was designed to assemble and link files that changed since the last version of the executable was created. This saved me from having to track all of the modules that were changed since the last published version of the program and, as anyone that worked with assembly language knows, the modules and changes can be many.
My editor evolved from the simplest of programs to an application that served me and my colleagues well for many years. I recall one company using my editor’s file CRC capability to locate corrupt files and overwrite them with a “clean” copy of the files. These were certainly exciting times and the learning was of tremendous value.
That I wrote a software to essentially serve my own interests, only to see it become something greater than I originally ever intended is an accomplishment that could not have been predicted.
As time went by and word got around, I began to sell copies of my editor and saved enough cash to purchase Microsoft’s C compiler. I couldn’t wait to get started. I have written many custom applications for companies wanting that “extra special” feature that just couldn’t be found in their commercial applications.
Every day presents an opportunity to learn, to feed our imagination and insatiable curiosity, to become an expression of the way we think and the work we do for ourselves and in the service for others.
Two common questions prevail from anyone wanting to code:
- What language should I learn? and
- How do I learn to code?
As we may have learned from the TED Talks and from my own experiences, those questions are secondary. The real question should be “Why?” This is the motivating factor for all that follows – including language selection and discovering how.
I learned a language that was the only affordable option at the time – $85.00 MASM versus a $650.00+ C compiler. Today, I know many languages – each serving an application dependent purpose. I some cases where it’s a close call, I go with my favorite.
You can learn to code from books, online training, videos, webinars, attending classes, and participating in local “language chapters”. However, you only truly learn by doing – when you actually start writing code that matters. If what you are coding is truly a unique application, the code you need has yet to be written by you.
When I started programming, many of the libraries we take for granted today did not exist back then. This is especially true for graphical user interfaces (GUI’s) such as dialogue boxes, forms, and other features such as Directory / File selection or other operating system level interfaces. Everything had to be written from scratch. Imagine having to write a “square root” function in assembly language!
Are we having fun? Absolutely! Nothing beats the satisfaction of watching your code execute flawlessly in front of happy users!
