|
|
posted: April 29, 2023
tl;dr: Amazing things can sometimes result when software developers are allowed to work on whatever they please, part two...
(continued from part one):
I’ve seen plenty of examples of software serendipity throughout my career, but a second one that stands out concerns the product I wrote about in Internet access fit for a king, the ADC Kentrox DataSMART.
The DataSMART, when it was first launched, featured a clunky user interface. The device was supposed to be set up and configured once and then remain in service for years, hopefully running trouble-free without further human intervention. On the front panel were some LEDs, buttons, and even a thumbwheel switch. Clearly you couldn’t do too much via the front panel. For more in-depth configuration and monitoring you needed to attach a terminal, such as a portable computer (laptops were just coming into vogue) or an actual terminal (laptops have pretty much replaced these), via an RS-232 serial port cable. After cabling up your terminal device and setting the baud rate, you could gain access to the DataSMART’s software-based user interface. The user interface featured alphanumeric characters only (no graphics) and was organized into menus, starting with a top-level menu. You hit keys on your keyboard to navigate your way down through the menus until you found what you wanted to see or change, after which you would jump back to the top and perhaps do another operation.
It worked and it was better than some of the alternatives of the day, such as command-line user interfaces that required the user to remember and type commands. But this was in the mid-1990s, and graphical user interfaces with windows were all the rage. The Macintosh started this revolution in 1984, and by the mid-90s Microsoft was having much success with Windows. Microsoft also developed some tools to make it easier to build graphical applications that ran on Windows, one of which was Visual Basic.
It was a huge improvement to add a GUI to a product whose main front panel input device was a thumbwheel
Most professional software developers at the time derided Visual Basic, perhaps because of the name, which suggested a lineage with the BASIC computer language. The “B” in “BASIC” stands for “beginner’s”, and I did use it to write my first code. But I, like most software developers, quickly graduated from BASIC to more powerful programming languages. I never used Visual Basic, and would have considered it a step backwards in my career. It had the reputation of being a simple language that less-skilled programmers, especially part-time programmers who worked in Information Technology (IT) departments, could use to hack together simple applications to automate minor business processes.
There was one software developer in the engineering department at ADC Kentrox who wasn’t afraid to use Visual Basic. He saw it as an opportunity to make a major improvement to the DataSMART by creating a Graphical User Interface (GUI) for the device. He realized that, with the rising popularity of laptops, more of the devices being connected to DataSMARTs in the field via the serial port were laptops, specifically Windows laptops, and those Windows laptops could run a Windows application written in Visual Basic. He set about to, in his spare time, write a Visual Basic application that could present a nice, friendly, graphical user interface to the user, while translating all the user’s actions into the character-based menu operations necessary to actually operate the DataSMART.
Not only did this run counter to the language biases of the department as a whole, but it also ran counter to the department’s strategy for improving the management of the DataSMART. We were executing a multiphase program to add Simple Network Management Protocol (SNMP) functionality to the DataSMART and other devices. The SNMP initiative fundamentally involved adding a new command and response protocol to the device, which other computers and management systems could use to operate the device. If a GUI were to be developed for the DataSMART, it should use SNMP, not the old menu-based user interface. But the Visual Basic developer went ahead and used the menus anyway.
It worked, and people loved it when he unveiled it. I should say most people loved it. Customers loved it. The Sales team loved it, as it gave them something exciting to use in their product demos. The head of the Engineering department loved it; he was a big believer in software serendipity too. The main naysayers were the other engineers in the department. Visual Basic? Using the menu interface instead of SNMP? This was not a serious piece of software, it was a toy.
It might have been a toy in the eyes of some, but it was a wildly popular one. It helped grow the popularity of the DataSMART, which became the number one revenue product for the company. There were other reasons for DataSMART’s success, starting with fixing the stability issues in its embedded software, which I describe in my How lint made me a fortune post. But the Visual Basic GUI definitely helped, and it came from the mind of one software developer, pursuing an idea he had in his own time. That’s software serendipity.
Related post: Internet access fit for a king
Related post: How lint made me a fortune