My boss, Ralph, called me into his office one day in 1984 or 1985 and asked me to go to a meeting with him. He briefed me that there was a problem with the code that our project was using for tracking the detailed project expenses. Our project was in the midst of a big construction for a demonstration and we had our own code that allowed us to track our money and budget to a finer detail than the standard business systems tracking employed at our site. Although, we were in Laser Systems Analysis group and responsible for the laser design and analysis modeling and simulation codes, Ralph had been asked to look into the situation by his boss. So, there we were.
In the meeting there was a half dozen individuals that I hadn’t met before. The only people I knew were Ralph and his boss. We sat and listened for I can’t remember how long, as each individual told us that the code was broken but how this or that couldn’t be done to fix it. I can’t remember now if the problem had existed for weeks or days, but it was long enough to cause great concern and it didn’t appear that it was going to be fixed anytime soon. Of course, they were on the spot, but we were getting excuses and rationalization and no answers. At some point, I think I finally turned to Ralph and whispered, “I’m getting tired of hearing what can’t be done.” Ralph nodded in agreement.
A short time after that meeting, Ralph and I had our hands on the source code in question and were tasked with fixing it. I don’t think the people in charge of the code really minded, since they didn’t think we would succeed. Upon looking at the code, we could quickly see why there were real problems fixing this code and keeping it running. The code was written in old style FORTRAN. The logic thread was a real spaghetti mess. Large sections of the code weren’t even used any more, but that wasn’t always obvious, and variables had short, cryptic names which didn’t help us to understand what the code was doing. After Ralph and I assessed the code we came to an agreement that in order to fix it we would have to rewrite the entire thing.
So, Ralph and I rolled up our sleeves and started working through the source code. Going through every line from start to finish. Deleting code that was obsolete and rewriting it into a more modern structured style. Ralph and I broke it up and both started working on it in our offices. At times, we worked together and at other times we took turns. Tag team programming, with one person at the terminal and the other looking over his shoulder helping. We worked together like that all through the night and into the next day.
I forget the original name of code, but for convenience I may have shortened it to DF. As we worked through multiple major versions of rewrites, I remember simply labeling them A, then B, then finally C, thus DFC. The final pass through the code resulted in a version that successfully ran to completion and didn’t suffer from the bugs that had plagued the original code just the day before. By that point, Ralph and I both were both exhausted and referred to the code as “the f*ing code”. However, I think we told everyone else that DFC stood for something Financial Code or something.
I’ve always felt that the DFC experience was an important lesson for me. Ever since that experience, whenever I catch myself in a meeting explaining why something can’t be done, I’ll remember DFC. Then, I’ll sit back and try to think of what can be done and go do it.