Yep, we were carving symbols out on rocks!
I still remember the day a friend of mine got an Apple II computer. We were stunned that he had this in his house and was able to create programs in BASIC and store them to a floppy disk. Not only that, but he create a program that he could run to actually open and close the shades in his bedroom. How cool! Another buddy of mine had a TRS-80 and the storage system on his computer was a cassette drive – for those that don’t remember, this was a painfully slow way to load data/programs into memory. Additionally, the TRS-80 regularly lost information on the cassette tapes. It was not uncommon that you had to store something on 3 or more different cassettes to actually ensure that you had a copy that worked.
Today, I wear more computer power on my wrist then what was available on the mini-computers that I was programming back in the day. Seriously, my Apple Watch 3 has 768MB of RAM and 16GB of storage. The S2 processor on the Apple Watch 3 runs at 780 Mhz. As a reference the IBM 5110, which was the first computer that I professionally programmed on, had 32K RAM (could be expanded to 64K), with two 1.2Mb floppy drives and a processor that ran at 1.9Mhz. The IBM 5110 had a retail price of $10-20k depending on options, it had a 5 inch black and white screen (16 lines of 64 characters) and weighed over 40 pounds. And yet, somehow we made things work!
My how times have changed!
One of the first professional programs that I wrote managed a customer list for a business using the IBM 5110. The customer information was spread out over multiple 8” floppy disks (side note: I still have copies of the original programs and data on the 8” floppies – not sure I could even find the equipment to read them at this point). During processing of the list, the computer would prompt you to change the floppy disks so that it could continue processing the data. It was clumsy to say the least and meant that someone had to babysit the programs when they were running, changing disks back and forth as needed. And to complicate matters further, there was no such thing as a database – your data was written to fixed length ASCII files and you had to manually read/write and manipulate the data off the floppy disks. All those fancy things that SQL does for you in retrieving, manipulating, sorting, summarizing and managing data, had to be done by hand. I remember spending huge chunks of time writing generic BASIC PROCs to handle common functions that can now be done with a single line of SQL.
Creating the programs was interesting to say the least – there was no internet to look things up or to turn to when you needed help. You pulled out the programming manuals from IBM and you were on your own to plow thru the manuals and piece information together. The IBM 5110 could be programmed either in APL or BASIC – you literally had to flip a switch on the front of the computer to tell it whether the programs you were running were written in APL or BASIC. I wrote the programs in BASIC and they were not structured – lots of GOTO and load PROC statements. I think back on how I created those programs now and shivers run up and down my spine. But, that was just the way it was done. That was cutting edge back then – remember, the IBM 5110 was the precursor to the IBM PC.
If you want a blast from the past, check out the IBM Reference Manual for creating BASIC programs on the IBM 5110: http://www.bitsavers.org/pdf/ibm/5110/SA21-9308-0_IBM_5110_BASIC_Reference_Manual_Jan78.pdf
Today, I don’t program during the day. My role is different, and that’s ok. I’m leading 120+ team members, ranging from our Enterprise Architect and Tech Leads, to Software Engineers, to Quality Assurance Analysts and Test Automation Teams. So my coding is limited to my playing around at night to keep my skillset relevant and to ensure that I can still engage in technical conversations with my teams. Occasionally, I will do some volunteer work – coding where I can make a difference for a non-profit or helping out when a business owned within my family needs some coding done.
Lately, I’ve been creating an application using Ruby on Rails with the backend database running on MySQL. What a leap from the old days! Ruby, used correctly, is a dynamic, interpreted, object oriented programming language. The addition of Rails provides a full Model-View-Controller framework that can be used to quickly build sophisticated web applications. It provides the underlying framework for accessing various databases, providing the web services layer and generating the web pages for the application. What used to take me hours or days to accomplish writing out programs on the IBM 5110 I can now do in a matter of minutes. I spend a few minutes describing an underlying table, then I tell Rails to generate the scaffolding around that table to create a base controller and view that I can then tweak that controls all of the standard Create-Read-Update-Delete (CRUD) activity. The screens generated are not pretty, but they get the job done and I can then go back in and tweak them to give them the look and feel needed by the app. I can also tweak the controller to add additional business logic where it is required to meet the needs of the business.
I’ve also been playing around with a personal application I’m writing for the iPhone and Apple Watch. I’m using Swift for that particular effort. I’m conflicted here, I love Swift, but I absolutely detest the Apple tool to create the UI/UX. The tool included in Apples development environment is not intuitive and is over complicated. I consistently get that feedback from other developers that I talk to. They love Swift, but can’t stand the way that you have to create the UI/UX for an app. In fact, I have to say that my distaste for the UI/UX development interface has caused me to walk away from the app several times, I do eventually come back to it because I really want to make this app work, but I’m looking forward to third party tools that may allow me to replace the Apple UI/UX builder. (Yesterday, Google announced that Vesion 1.0 of Flutter is now available, providing a write once deploy to both Android/iOS tool – this may be my option, although the Watch interface will still most likely have to be done in Swift.)
Think about all of this – the first programs I wrote back in the day were massive, thousands of lines of code written in a messy BASIC with undecipherable GOTO or LOAD proc commands sprinkled liberally thru the code. Additionally, variable names were limited in size and were generally cryptic – where today, you can have variable names that are very descriptive and don’t leave the next person touching the code guessing as to what a variable is being used for in the program.
Time has allowed us to mature how we approach software development. We now have languages, frameworks, tools and integrated development environments that allow us to create code that is easier to read, is more elegant in the way that it handles data and processing and also is easier for the next person to pick up, understand and modify. We have developed tools to share code that is being developed and that allows groups of distributed developers to easily understand what has changed since the last time they pulled a copy of the code – I remember sharing code by exchanging floppy disks, yikes! We have backend data storage SQL/NoSQL that allow developers to store millions of records and quickly access, manipulate and change the data. We have developed new languages that allow us to do things with a few lines of code that used to take pages of code to accomplish. The code is now written using Object Oriented models that allow us to more accurately describe the things that an application is manipulating and gives developers a better way to create and manipulate those things. We have moved to development paradigms that make us more productive – test driven development, WAGILE (Agile-Waterfall Hybrid), Agile. We have introduced tools that allow developers in disparate locations to interact and solve problems in real time – SLACK anyone?
As a profession we need to continue to challenge ourselves in how we create software. Ultimately, it is about solving real problems for people. I don’t necessarily care how sexy a new tool/language/framework is, if it doesn’t allow me to streamline how I design, code, test and deliver the solution to the customer, I have a tough time justifying using it either personally or within the teams I am lucky enough to lead.
The current state of software development has advanced significantly from the late 1970’s and early 1980’s. That said, we can’t afford to stand still, we must understand the new waves that are heading our way. How will machine learning and artificial intelligence allow us to change the way we design, develop, test and deliver software. Will AI augment or replace roles within our teams? What pressures will the cloud continue to put on us? Today you can spin up a company without having to purchase the underlying hardware to deliver your services – you can use AWS and do a pay as you go based on the actual usage of your application. Where does it make sense to put infrastructure in the cloud? Has your organization begun using containers to deliver applications and services? How is your organization dealing with the pressure to deliver features faster – sprints anyone?
Last year, over Christmas, my son wanted to explore Artificial Intelligence. So my wife and I purchased several books on the topic. After opening these on Christmas, he holed up in his room one day and came down proclaiming at the end of the evening that he had built his first AI engine to recognize numbers in images. Uhm, what? Over the summer, before entering his first year of college, he took on-line courses to further his knowledge of machine learning. He as able to do all of this by reading some books, going on-line to do research and get questions answered and then taking some on-line courses to push himself. He is much further along the curve than I was, and has access to tools that I could only dream of. His generation will be the ones leading the wave of new paradigms into the companies we all work for today. What change will they bring with them and are we preparing ourselves?
I’m excited to see where the future takes us as a profession and how it will change what we do as developers. One of my challenges will continue to be to identify how we integrate these new ‘things’ into the legacy applications we support (and, yes, that means all that fancy code you are writing right now will be legacy code that has to be retrofit tomorrow)!
Welcome to the future …
If you'd like more information on my background: LinkedIn Profile
