The End of Custom Software
THE BEGINNING
Right out of school, I went to work for a family-owned business that specialized in document workflow and imaging (COM Squared Systems, now owned by Milner Technologies in Atlanta, GA). The first task they gave me: build a multi-port facsimile server for their banking customers. I didn’t really know what a fax was - this was 1991. I had worked as an intern for a couple of years writing C code for Windows (starting with 2.0), so how hard could this be?
I started with an 8086 PC running MS-DOS and a multi-port fax board from OAZ Communications. I had four phone lines I could use for testing and development.
Step 1: Write a device interface for the OAZ board to use with MS-DOS (more on that in a moment).
Step 2: Code-up user interface primitives to write directly to the video card memory regions that represent the pixels on the screen, custom building things like message dialogs, status tables, and button visuals to trigger the function of various F-keys to control the fax server.
Step 3: Build a DOS TSR (terminate-and-stay-resident) to handle firmware interrupts from the fax board to capture input from the phone lines (you know, the actual fax images). Oh, yeah, the fax images. Those are a stream of ones-and-zeros that conform to the CCITT Group 4 protocol for fax image compression and transmission. Which led to…
Step 4: Build a CCITT G4 en/decoder, because remember I started from nothing. Well, not nothing; I had my util.c library of various utilities that I brought with me from my internship with the University of Minnesota’s Civil Engineering Dept., which became Image Sensing Systems (still in business; I worked on the first AutoScope writing math routines to help remove artifacts during machine vision processing).
There was no Stack Overflow or Google. We had a UUCP server for access to the pre-consumer Internet, but that was mostly used by the other developers to interact with message boards like alt.tasteless (which is just what it sounds like).
No, getting code developed to interface the OAZ fax board with an MS-DOS TSR required picking up a wired telephone and calling OAZ Communications technical support. I am still amazed to this day that there was someone on the other end of that line that would pick up a phone call and answer technical questions.
The MS-DOS TSR was a really frustrating development environment. Basically, a TSR was a sad attempt to add background processing to a single-threaded system. The TSR was essentially an interrupt handler from the fax board that passed references (i.e. pointers) to memory areas shared between my DOS app and the OAZ fax board. There was no debugger, of course. Debugging things like race conditions meant constantly writing chicken scratch to the video buffer so that when the system deadlocked, at least there was some text plastered on the display. This would, maybe, give me a clue as to what was happening when my own, stupid logic errors manifested themselves.
Today's developers could not comprehend the technical constraints within which we had to operate in those days. I am dying to tell a recent anecdote here, but let’s keep moving.
Building early user interfaces was equally annoying, requiring the programmer to write hex codes to video card memory regions that would translate into pixels… all 640x480 of ‘em using glorious 8-bit color. I had to build a toolbox of video primitives, starting with message boxes and button-like things that were tied to keyboard interrupts (i.e. you press F2 and something happens).
Bonus points for you if you ever played Leisure Suit Larry. The image above was the best I could do for a screen capture - we didn’t walk around with cameras on smartphones back then, so I don’t have any fax server screens I can show you.
As you can imagine, all of the above took about a year to build and ship out to customers, which were large banks. What do you think happened when I left COM Squared Systems? Because, yes, I worked alone on all the above.
THE CONSUMER INTERNET
The Internet has been around since the '60s. But for most people, Al Gore invented it in the early '90s. Along came the first websites, browsable with Mosaic and later: Netscape, whose legacy contribution to the 'inner-tubes' was JavaScript (JS). JS is a language that was initially used to provide user interface functionality but has been extended to absurd levels for both front-end and back-end development, to the point where many commercial software systems are written entirely in JavaScript.
Early websites were all coded by hand with text editors using HTML markup, which was later enhanced with cascading style sheets (CSS) and, as noted above, enhanced with embedded JS.
In the mid-to-late '90s, web pages could be designed with WYSIWYG (WIZ-ee-wig) or What You See Is What You Get development tools, like Dreamweaver and Microsoft FrontPage.
After some time went by, it seemed ludicrous to write markup by hand, unless you were doing something on the bleeding edge. By 'bleeding edge', I am referring to high-profile marketing sites that became known for pushing the boundaries of what could be realized within a web browser. Remember Parallax scrolling?
CLIENT-SERVER ARCHITECTURE
Client-server computing refers to software running somewhere that serves data, web pages, et al., to many clients running on a network.
Client-server computing has a long history that goes back to the '60s and '70s when developers wore button-down shirts and ties, and programmed with punch cards and reel-to-reel tape machines. When I was starting out, those were the gray beard stories I rolled my eyes at, much like how you are rolling your eyes now at my fax server story.
But the advent of the Consumer Internet really brought client-server architecture to the mainstream. In today's vernacular, you speak of an APP that is connected to THE CLOUD.
The Cloud has turned into a Swiss Army Knife of storage and services, empowering the development of back-end services that are highly available and scale to levels previously unavailable to all but the wealthiest IT organizations. Well, until AWS has a hiccup, which now seems to bring down the entire internet and all of your home appliances with it.
Commercial cloud services are a double-edged sword in that you have less control over their implementation, and you are beholden to their rules, but you are also leveraging a larger, more experienced team to craft the building blocks, so to speak. But you are still writing code to interface with and leverage cloud services, still building custom software for your organization (or clients).
THE END OF THE BEGINNING
Looking at the evolution of software, everything leading up to today has been about custom software development. The software playgrounds keep changing: green screens to web browsers and web-based apps, mobile phones, and their apps, cloud-connected devices (IoT) with their limited ability to interface with the people they serve, are all driven by custom software.
As time marches on, the boundaries between what you write and what someone else writes (and shares or licenses) keep shifting.
Now, with the newest generation of low-code platforms, we can finally realize the age-old vision of building apps and services by simply snapping existing things together.
For app developers, low-code brings the focus back to user research, experience design, usability, usefulness, and compatibility, and away from complexity, risk, drawn-out development timelines, and obsolescence. This ‘end of the beginning’ in technology will drive exponential growth in innovation because the barrier to entry is more accessible and inclusive to a diverse group of implementors.
More accessible to a diverse group of implementors… that is the real change that marks the end of the beginning. When I speak of diversity in this context, it is about skill sets as much as it is about people.
Low-code solutions reduce risk, cost less, and take less time to build, and minimize the proprietariness of custom software by replacing programmatically accessed services with existing, managed platforms that are accessed by a user interface (e.g. web pages, a mobile app, or a desktop client app).
Going back to our Consumer Internet discussion, we may illustrate the key difference between custom software vs. low-code by comparing how websites were/are built. While WYSIWYG tools like Dreamweaver replaced hand-editing of HTML, you still had to stand up a web server; you still had to understand HTML to create your digital presence. This scenario moved into tools like WordPress and hosting sites like GoDaddy. Ultimately, with today’s Content Management Systems (CMS), like Squarespace or Shopify, building even a large eCommerce site requires little more than a credit card and a few clicks.
More importantly, your new eCommerce site is not a hostage to be used by your developer/agency to lock you in.
When your eCommerce site is built and deployed using a popular CMS, like Squarespace or Shopify, the developer/agency is figuratively handing the keys to the car back to the client, eliminating the client's risk almost entirely. Many of our clients came to us because they were previously burned by custom software: price gouging for even the smallest changes after release or, worse, the developer/agency fails to deliver at all, leaving them with a pile of code that the next team declares as worthless, forcing a complete reboot. Low-code eliminates developer/agency lock-in, allowing clients to take ownership over their product, putting them back in the driver’s seat. Don’t like your logo? Just log into your Shopify account and simply change it.
Even as automated code generation coupled with app-managed, cloud-hosted services expand in breadth and depth, much of what knowledge workers interact with is still custom software. But these sea-change innovations mark the beginning of the end for custom software. Well, okay, to paraphrase Winston Churchill: maybe not the beginning of the end, but certainly the end of the beginning. The thought of building custom software will seem as absurd tomorrow as the opening fax server anecdote seems today.
Fast forward to today, KRUTSCH is a digital product design agency based out of Minneapolis, MN made up of an in-house team of talented creatives and developers, proven experts in design for mobile and web applications, since 2010.
Every single one of the mobile and web applications we have designed and built over the last 12 years has been a variation of custom software. Everything from Java to Windows Presentation Foundation to HTML/CSS/JS to Kotlin and Swift.
Every single new client solution we are designing and building for tomorrow is based on low-code platforms. You still need great user experience research and design, which is what we bring to the table. And, you still need some code to bridge functionality between cloud solution platforms. After all, not every web app is a Shopify store or a Squarespace website.
But low-code has changed how we sell our services to future clients and what we experience with our sales process: going from curiosity to interest to proposal to contract to invoice to delivery. When we pitch a low-code solution to a prospect, and we are competing against agencies that are pushing custom software, we win the business every time. We literally close with: when we are finished, we hand you the keys to your new car and you do with it as you like! We are always here to help, but our clients are not beholden to us for even the smallest changes to their web mini-site or app.
In the weeks ahead, we will provide real-life examples of how Think. Code. Go.®, a design studio within KRUTSCH, designs and delivers low-code solutions, as well as why this approach resonates so strongly with our clients. Stay tuned for updates from our designer/developers with case studies and no-holds-barred appraisals of low-code platforms.
Ken Krutsch is Founder & President of Think. Code. Go. ®, the design studio within KRUTSCH. From concept to delivery, Think. Code. Go. specializes in designing consumer-facing apps and mini sites. We generate and execute ideas, finding opportunities for our clients to innovate. Because solving the right problem builds careers, organizations, and professional relationships.
Sophie Stephens is the marketing and public relations strategist at Think. Code. Go. ®. With a demonstrated history of working in multiple industries, she loves to build relationships and bring strategic ideas to life to promote business growth.
