In 1994 I accepted a contract with Intel on a project that I believed was far beyond my ability, I was an unabashed imposter and was hoping to get a few paychecks to get caught up on my bills before my inadequacy was discovered. That’s not what happened.
Intel (Folsom, California) was a horrible place to work. We were doing a customer call center application and my desk was between a pair of CSRs who gurgled and chirped all day and an environment too noisy to think. They held endless meetings, not just one- or two hours but sometimes going three days, where I was the only member of the team weighing under 350 pounds and had to watch these incompetents down glazed donuts all day.
My component was a desktop application I chose to write in Microsoft Foundation Classes but communication with its database was over a local stub that I connected to using Dynamic Data Exchange, DDE, an already obsolete protocol that was all but undocumented because Microsoft was, typically, evangelizing its successor, and articles that should have given me information I needed instead repeated the same stock marketing phrases on every page. “OLE exposes a higher level of abstraction. A higher level of abstraction. A higher level of abstraction.” I finally got unblocked by talking to the Massachusetts company that made the database, a name-value pair system, not relational. Oh, so WM_DDE_EXECUTE is unidirectional. Then I was able to work.
I tackled the project as best I could, fully expecting to fail. When I read their functional specification I identified dozens of errors, including the state transition diagram that was the basis of the whole project. The imposter feeling started t go away.
OK thanks for reading this far. I broke the project down into components, OBJECTS to you nay-sayers, with clean isolation of interface and implementation, and developed them separately. I didn’t have any way to test them, nobody was talking this “unit test” horseshit back then. But they were simple. Then I realized what was happening; I was doing object-oriented programming. I decomposed a project that was in its entirety beyond my grasp into components that I could grasp. I coded them piece by piece; the database transport later, the front end, an error-handler, a parser for the DDE protocol.
Management was getting concerned; I didn’t have anything that worked yet, I was obvious writing code but nothing could happen until most of the pieces were done.
Then one Tuesday I realized I had enough to make a trial call.
Everything worked. Everything I had written and hadn’t tested, worked. I called over the Intel honcho and showed him. OK, he said, get the caller’s phone number. I looked up the tag in the returned DDE and added a few more lines, ran it again, and printed the number to an available text control. I read it to him.
They were freaking stunned. They knew what I had done, and understood that I had decomposed the huge project into manageable pieces OBJECTS TO YOU. They talked to my agency and told them that they recognized me as a stellar developer, and they didn’t want to waste any more of my time on meetings, that I should be excused from nearly all of them so I could work.
To be excused from a meeting at Intel was equivalent to being voted the new Pope.
This was my first application of OOP and it earned me not just the respect but the admiration of some very senior managers.
I know what functional programming is and yes there’s a place for that. But as with all the horseshit you guys babble on about, Agile and Scrum and Design Patterns and blah blah blah, it is nothing new, just a new name for something we’ve been doing all along so you guys can polish your cocks about how “up to the minute” and sooooo coooool you are using all the latest cool neologisms. “Stories” (spits).