As a follow-up to my previous post, Youth is Wasted on the Young, this post will give a personal example of how valuable experience can be.
I was working on a project back in the late 90s on a 2-month contract which lasted over 2 years. I was hired as a C++ consultant to help them with the communication protocol between a VRTX real-time operating system application and Windows NT. Yeah, this dates me a bit but this will help explain may major point of this post.
On my very first day, I sat in a meeting with the lead developer discussing his protocol design along with six or so other developers. I was new so I didn’t interject and just listened. If you know me, you then know how hard that was for me to just listen.
The lead developer explained how he was using TCP via sockets to communicate between the VRTX application and the Windows NT application. He designed a protocol request and response packet for each command. There were over 100 commands and they were all different structures and even the responses were all different. This meant there were potentially over 200 separate formats. I noticed very quickly that he was going down a dark path full of gotchas. But, I smiled and listened. After three hours or so, I decided to interject.
You see, at that time I knew TCP/IP like the back of my hand, which is the main reason they hired me to work on this particular project. Years earlier, I wrote the TCP/IP protocol as well as the Remote Boot protocol in assembly language using only the RFCs. All of the code had to fit on an 8K EPROM on an NCR Ethernet card. I remember trying to cut 20 bytes out of the assembled code so it would fit on the 8K EPROM by changing things like "MOV AX, 0" to "XOR AX, AX" which changed it from 5 bytes to 2 bytes per instruction. Fun stuff. So, I love TCP/IP. It's the backbone of the Internet. But, you don't have to write to TCP/IP much anymore.
Anyway, back to my story. I asked the lead developer a few questions. Let’s call him Bill. It went something like this.
“Bill, I don’t know much about VRTX but I know it’s a real-time OS and is like Unix in many ways but is a real-time kernel, right? Bill said, “That’s exactly right.”
“Well,” I said, “it seems to me that VRTX should have Remote Procedure Call (RPC) functionality like most Unix systems do. Can we check?”
Bill was more than a little bit perturbed but I knew I couldn’t sit in the meeting any longer without saying something. It was like watching a train wreck in slow motion and containing myself just wasn't an option.
One of the guys in the room ran out and grabbed the VRTX manual and started thumbing through it. In the meantime, Bill asked what RPC was and I began to explain.
I told him that he was basically re-inventing the wheel with his protocol design. Not only that, it wasn’t consistent, not easily extensible, and with over 100 separate commands with their own format structure it would be quite difficult to both implement and use. I told him that RPC solves these problems. RPC handles the all of the underlying mess that he was creating and allows the developer to make simple procedure calls that would then be executed on the remote machine and return the results. It took care of formatting of strings, numbers, structures, etc. I knew of an RPC library which I’d used in the past that ran on Windows NT so I was fully aware of RPC as well as its underlying protocol.
The developer thumbing through the manual interrupts and says, “Yes, VRTX has RPC.” I said, “Great! Can I give it a quick try?” There were a few more questions and answers and then I had one developer write the code on the VRTX side and I wrote the C++ code on the Windows NT side with a simple hello world remote procedure call. In less than 15 minutes we had a functioning RPC call from Windows NT to the VRTX OS, which basically did away with everything that Bill had been working on.
The manager called me into the office a bit later because Bill had gone to her and complained about me. I didn’t know this because I just thought I was helping. The manager asked what happened and I told her. She was excited that we found a better solution. She added that Bill had been working on this protocol for a while and it was holding up the project and I solved the problem in just 4 hours. He'd been working on this for 4 months and no code was written. Not one bit.
This is the value of experience. For me, it was just something I knew. I didn’t know that nobody else in the room didn’t know it and I got the experience only by doing it previously. But, the fact that I did have the experience is what helped them get the project completed. I’ve seen firsthand on many occasions and this is but one example of how experience won out over youth and exuberance. You may initially pay more for experience, but youth and exuberance may cost you more over the long run.
At the same time, you need a healthy mix of youth along with experience. Sometimes experience can be a detriment. Sometimes experienced developers get an a rut of doing the same things the same way and are resistant to change. This is where youth comes in to help them out of the rut and think of software development in a new way.