Try Noodling on That

The name of this blog is a reference to words uttered by a friend of mine. He also added the word "noodle" to my vocabulary, which is synonymous with thinking in this context. Not to be confused with a Noodle the pug who prognosticated on what type of day we could expect to have.

Whether to myself or someone on my team, I often use the phrase "noodle on that" when the answer is non-trivial and analysis and logic are not yielding a solution. It can be relatively straightforward—I need an answer to this problem—or something more abstract—like ideation. Either way, there are times when looking for an answer is more like chasing something elusive. Finding the answer is often further compounded by some time pressure - I need to solve this by XX.

Enter Noodling.

Several times, the answer presented itself to me - but only when I took the pressure off myself. For instance, I was cramming for a math final, and the answer to a particularly gnarly calculus problem came to me in my sleep. It woke me up, presumably so I could write it down (ha). Another time, the answer came to me in the shower. Someone once attributed this to all the positive ions stimulating my brain. Whatever the reason, it's a thing - Shower Epiphanies.

As a manager, I have often suggested that they take a break from trying to solve the problem directly and noodle on it. Give yourself a break. Let the pressure off. Give your subconscious a chance to work on it. My anecdotal data is that it works the majority of the time. This has the additional benefit of letting people work it out for themselves. My belief is that things feel better when people figure something out on their own, as opposed to me giving them the answer. 

See you on comfy mountain. IYKYK.

A Brief History of Integrating

I was recently asked how I would integrate systems with similar functionality but different code bases and infrastructure. It got me thinking about how I feel I have been solving the integration problem throughout my career and how it (not surprisingly) keeps coming up. My answer was: It depends on what you have and where you want to land. I have many questions: how much of the data is the same? How reliable is the data? Is there an appetite to reduce any duplication? What is the desired recency (age) of the data? Is there a goal to become more homogenous? Regardless of the answers, I have employed several strategies/technologies over my career.

One of the first implementations I worked on was a practical solution for a PC-based application to leverage COBOL code on the mainframe. The company had invested years in the code and was not ready (or able) to rewrite it. We built an LU6.2 gateway to call the mainframe and pass data to the COBOL file's copybook. This was such a common need that later, Microsoft wrote an LU6.2 connector to create a code proxy from the copybook for you. Here we are 24 years after Y2K, and I am willing to bet that the banking and finance sectors still have a bunch of COBOL being used.

During the Object-Oriented boom, there was a big push to build an Enterprise Service Bus (ESB). We talked about technologies like MQSeries, CORBA, and RPC as ways to implement an ESB. I never saw an ESB I liked, probably because so many were never finished. Instead, I watched enterprise architects trying to resolve the enterprises' requirements into something for everyone. It's hard enough to nail this down for a single business line in an enterprise, much less many/all of them.

To some extent, we used databases as the point of integration. One system would be declared the data owner and copies of that data would be made for use by others. At the time, I saw this strategy fail more often than it succeeded because the copy would become stale and not meet our customer's expectations. Nowadays, we make copies, but it's less about integration and more about scale. To succeed, we had to figure out how to work in the world of eventual consistency.

As I shared these examples, I couldn't help but think of a few other topics. But these are the ones I wanted to share. If you've been in this industry for any time, I'm sure you have your own integration history. Integration is a persistent problem, a challenge that we all face, and it's safe to say that it's not going away anytime soon.

Things That Make You (Me) Go Hmmm

I saw a snippet of Captain Hindsight from South Park the other day, and it made me think of a couple things that have been rattling around in my brain lately. My initial college major was teaching history and political science; I changed after my freshman year to computer science. I still like teaching and history. Lately, I have been looking into challenging history as I was taught, looking to understand more of the complexity and unbiased events. For instance, I have been reading about the 1980 "October Surprise" story surrounding the release of the hostages from Iran. The timing of the release of the hostages was always a little suspicious, but not so much that I thought there was something else going on. In retrospect, there is much circumstantial evidence that it wasn't on the up and up. 

Hmmm. 

Where am I going with this? Hang with me.

You would have to live under a rock not to have heard unfavorable news about Boeing over the last few years—the 737-Max, 777 a whistleblower dying, and door plugs not being secured. Some people point to a more significant cultural change at Boeing that can be traced back to Harry Stonecipher, a protege of Jack Welch. For more on the Boeing story, see "Flying Blind" by Peter Robinson.

Hmmm.

I am getting to the point, really.

This got me thinking more about Jack Welch and how he made Six Sigma a pillar of his business strategy. As someone who has led medium-sized teams and big projects, I have always been cautious of Six Sigma. Like most things, it was started to meet a need and add value, but my experience has been that it's become something else. At GE, it was weaponized and became a "religion" to help with the culture. Want an example? Stack-rating employees, considering the bottom 5% of expendables, can be traced back to practices at GE. This practice has become common at most companies I have knowledge of. As a manager, I have had to use this practice on high-performing teams and replace the "bottom" person. The position stayed open for a long time because the person we managed out was very good and not easily replaced. Now imagine teams/organizations playing politics and/or pushing an agenda and how this can be used as a weapon.

Hmmm.

Funny how more information comes out over time, and it changes the narrative. Makes good fodder for someone who likes to learn.