We were asked to describe the simplest, most amazing code we had ever written or witnessed.
My answer should probably be some esoteric APL code that I personally wrote, like inverting a matrix with a single character program, but many of my readers wouldn’t understand it. In any case, modesty prevents me from choosing my own code.
So, instead, let me tell the story that took place long ago when we were installing an IBM 709 in Bermuda, as part of the NASA space-tracking network. The 709 was a “naked” installation, with little surrounding peripheral equipment, and nothing like it in Bermuda to help us.
In particular, we didn’t have an off-line printer or a punch-card duplicator, so we needed to use the 709 itself to do these jobs—but we had no utilities because we were probably the only naked 709 in the world.
My colleague, Marilyn, who was by far the best programmer I ever knew, went to our keypunch (the only unattached peripheral we had), inserted a blank card, and proceeded to punch (in row binary) a card-to-card duplicator program for the 709. She did it as I watched, in a single pass through the keypunch.
You’d have to understand row-binary format to appreciate what a feat this was—multiple punched columns of alternate instructions in binary. To top it off, she actually punched in (in the same pass) the self-loading program AND the parity check row for her entire card.
She then loaded this card into the 709’s card reader, picked it up and reentered it as input to itself, and so punched a duplicate. She took the duplicate to the keypunch and added one punch to one of the rows. She now had a 709-to-printer program—two incredible error-free programs for the price of one.
I’ve never seen anything like it before or since. Until that time, I thought I was a pretty good programmer. After Marilyn’s feat, I realized that the best I could ever hope to be was Number Two.
How about you? Any amazing code stories to share?
8 comments:
I've receive several fascinating emails and tweets in answer to my rquest for other examples. I'll post some of them as comments, if the authors permit it.
Norman Dorn wrote:
At Westinghouse Electric, I saw several feats of logical magic.
A. To diagnose a memory problem, an engineer entered a one word closed loop into memory and set the IP to it. Result, memory power breaker operated for that bank of memory. His name was Ivan Lee Shaw; he is on LinkedIn. I used it myself a few times subsequently.
B. To correct a data capture error, an engineer entered a one word patch to a program in mass memory. Result, time resolution data at 60 divisions per second, captured correctly for reporting a sequence-of-events. This was built into the operating system capabilities, but was not at first properly used by me.
C. An engineer diagnosed a wiring error in a mass memory device by recognized the "zero-sector" bootstrap program in hex on a sector other than "zero". This was in the field at a nuclear power station. The device in place had had a "head-crash" and was being replaced by an expert service technician. The technician saw differences between the documentation and the actual stuffing of the controller "cards" and removed the cards not indicated in the documentation. Loading the programs images onto the replaced device did not succeed. It was in reviewing the sector images that this discovery was made, by me. The technician reviewed the wiring diagram in front of the customers electrical contractor and both concluded that the removed cards were correct as delivered. After the cards were installed, the loading of the programs images succeeded.
At Public Service Electric and Gas Company of New Jersey, I saw a minuscule piece of code diagnose both a software error and a hardware error in remote equipment. The software error produced a protocol "hiccup" on a particular data "miracle". Does this sound familiar? The hardware error was, in fact, an incorrectly set remote ID # Dual-Inline-Package (DIP) switch. The PSE&G tech had to go back to the remotes and verify the switch throws electrically (with a Volt-Ohm-Milliammeter (VOM)). He found it then. More experience on this is available.
At Bell Labs, I saw a simple event-oriented program (that I wrote) lead to the diagnosis of both a cold-solder-joint and an operating system bug. It was very productive of unearthing bugs in the several network element "Devices-Under-Test" (DUTs) under development. This source-code tool-kit was lionized across the network element development lab and was offered at Bell Labs UNIX Tools-Day '86. Much more detail is available.
Dr. Miro Samek has extended the idea of event-oriented programming into tools beyond what I have imagined.
Allowing myself a smidgen of pride: At Bell Labs, one customer's manager observed to me that "You have done things that others who are respected said were impossible. What's more, to appearances, you do them casually." I have used this on my resume and on my LinkedIn profile.
Norman's great examples remind me of the time in Geneva where I changed one digit in the job control language, where the change reduced the job running time from 4 hours to 4 minutes. Of course, the service bureau that was getting paid by the computer hour didn't like that much.
Neither did the two original programmers who were chastized for not making that tweak themselves in their original approach. Doing simple, brilliant things is not always appreciated by all involved.
(Jeff Winchell writing)
I didn't witness it and haven't seen the source code, but Ward Cunningham's original wiki was done in about 200 lines of code.
Eventually that feat turned into an amusing
http://wiki.c2.com/?ShortestWikiContest
to see who could write the least code implementing the minimum requirements to be called a wiki.
(Perhaps some entrants would also be good for an Obfuscated (whatever) programming language contest). ;-)
----
I briefly got the chance to work for Luong La when we were both at Microsoft. He architected and co-wrote a Business Intelligence system because Microsoft's Analysis Services couldn't handle data that large with query response times under 15 seconds (and the reports were important enough that Microsoft's CEO looked at them daily). My job was to optimize the SQL code from the initial version of this system that had been written by Luong and another person in about 6 weeks.
Normally I can get code 10 times faster without much work (and once improved queries in one system by a factor of over 100), but the performance quality of the initial version Luong wrote was so good I struggled to get 2 to 2.5 times performance improvement. There was one particular SQL construct Luong had written that I had never seen before. When I checked the SQL guy who's "seen it all" (Joe Celko), he had never seen this either ...and Luong doesn't focus his work on SQL. I was very impressed.
I need to dig up the email on this from 12 years ago so I can remember what exactly that SQL construct was, though I imagine all the changes to SQL Server since then have made that construct moot. But still, it was the most impressive thing I'd seen done in a database language.
Less impressive, but amusing, when I coded the best PC solution of the first PC/mini/mainframe ad hoc query benchmark, Ziff Davis hired a high-priced OLTP (?!??) DB-2 consultant, to implement the DB2 on biggest mainframe solution....
when he got his first query done, he was quite proud that it ran in 3 minutes.
Then he asked how fast my PC (using FoxPro) solution was.
It was 6 seconds. ;-)
A few more like that and he was replaced by the Architect of DB2 to code the rest of this published benchmark. It took a lot of tweaking and unethical removing of queries from the benchmark (because IBM was the publication's biggest advertiser) before the DB2 solution on a 10 million dollar mainframe matched the performance that I got on FoxPro on a 50K $ PC solution.
I enjoyed that, even if it was unfair to compare antiquated software with state of the art query processing engines like FoxPro was at the time. ;-)
I didn't witness it and haven't seen the source code, but Ward Cunningham's original wiki was done in about 200 lines of code. That example and remembering his simple mantra ("do the simplest thing that could possibly work") has inspired me to write some of my shortest programs.
Eventually Ward's feat turned into an amusing
http://wiki.c2.com/?ShortestWikiContest
to see who could write the least code implementing the minimum requirements to be called a wiki.
(Perhaps some entrants would also be good for an Obfuscated (whatever) programming language contest). ;-)
----
I briefly got the chance to work for Luong La when we were both at Microsoft. He architected and co-wrote a Business Intelligence system because Microsoft's Analysis Services couldn't handle data that large with query response times under 15 seconds (and the reports were important enough that Microsoft's CEO looked at them daily). My job was to optimize the SQL code from the initial version of this system that had been written by Luong and another person in about 6 weeks.
Normally I can get code 10 times faster without much work (and once improved queries in one system by a factor of over 100), but the performance quality of the initial version Luong wrote was so good I struggled to get 2 to 2.5 times performance improvement. There was one particular SQL construct Luong had written that I had never seen before. When I checked the SQL guy who's "seen it all" (Joe Celko), he had never seen this either ...and Luong doesn't focus his work on SQL. I was very impressed.
I need to dig up the email on this from 12 years ago so I can remember what exactly that SQL construct was, though I imagine all the changes to SQL Server since then have made that construct moot. But still, it was the most impressive thing I'd seen done in a database language.
Less impressive, but amusing, when I coded the best PC solution of the first PC/mini/mainframe ad hoc query benchmark, Ziff Davis hired a high-priced OLTP (?!??) DB-2 consultant, to implement the DB2 on biggest mainframe solution....
when he got his first query done, he was quite proud that it ran in 3 minutes.
Then he asked how fast my PC (using FoxPro) solution was.
It was 6 seconds. ;-)
A few more like that and he was replaced by the Architect of DB2 to code the rest of this published benchmark. It took a lot of tweaking and unethical removing of queries from the benchmark (because IBM was the publication's biggest advertiser) before the DB2 solution on a 10 million dollar mainframe matched the performance that I got on FoxPro on a 50K $ PC solution.
I enjoyed that, even if it was unfair to compare antiquated software with state of the art query processing engines like FoxPro was at the time. ;-)
- Jeff Winchell
When I was in college I had access to a CDC 6400 computer. Some of the most amazing subroutines were written for common functions like converting a binary number to a decimal number. All in assembly language, a lost art.
Peter De Jager wrote:
Saw this and the first thing that entered my mind was stuff I’d written in APL while working at I.P. Sharp.
Then I read the article.
Big cheesy grin.
Daniel Starr wrote:
Most straightforward and amazing code I ever saw came when I demanded a re-write of something another guy had coded from my design. The programmer was an expert at squeezing out every last clock cycle and byte, at the expense of creating incomprehensible spaghetti.
I told him it had to be redone, explained the notion of maintainability and gave him a bootleg copy of Myers's "Composite Design" (I think I also bought him a beer or two).
To my surprise, he took the lesson to heart and quickly became as good at writing clear, maintainable code as he had been at writing fast, small spaghetti. In fact, he became much better than me at this. It's interesting to to think I may have started a Buddha on his path to enlightenment.
Post a Comment