One of the highlights of attending the GPU Technology Conference in San Jose back in March was the keynote address by NVIDIA CEO Jensen Huang. Of course, there was the predictable push to sell more hardware, but notwithstanding the technology demonstrations were truly impressive.
There was an autonomous car in the parking lot. There was a driver in the conference room. Then, on the big screen, was the driver in the holodeck – the simulated environment for the real car out back. The real driver, in the virtual holodeck, seeing real-time data and imagery, drove the virtual car, which in turn drove the physical car safely into a parking spot. It was impressive. The processing power required to do this all real-time is barely imaginable.
But the biggest insight for me came from NVIDIA’s Director of Developer Programs, William Ramey.
AI is not Magic.
With all the mystery around Machine Learning and Deep Learning in particular, it was insightful to hear such a thing. The problem, of course, is that the hype is so great. It’s easy to assume that because this problem is hard, AI must be the answer.
His statement boiled down to this: If X then Y. Can the problem be defined so simply? Can a human understand, at least conceptually, the process? Is there a defined outcome? If all are true, then AI is likely a viable candidate. If a human can’t articulate the process, then don’t expect AI to provide an answer.
Ultimately it boils down to this: Could a human, with a lot of data and a lot of time, solve this same problem? If not, don’t expect magic from AI.
The seminar was an intensive on Structured Problem Solving, which I think is a term created by professor Patrick Noonan. A book may be in the works. I certainly hope so as there was tremendous wisdom and experience packed into these two days. Referring to the slide deck will help, but not the same way a comprehensive book would.
So what is Structured Problem Solving? It is a way to identify the real issue and then methodically move through various steps including research, task identification and communication, ultimately resulting in action. Be sure to keep the end goal in mind. Anyone who loves data understands that looking for other insights “just because” can waste a tremendous amount of time. That extra effort may be interesting but may not be aligned with the immediate needs of the company or customer. We had a great conversation about scope creep—and how that can come from both the requestor and from the team doing the work.
The high-level steps of Structured Problem Solving are:
Define the Problem
Break Down the Problem
Plan the Work
Work the Plan
Build the Case
Tell the Story
Start the Change
I have been in charge of software development teams of various size for over 20 years, including internal developers and outsourced teams. During that time, I’ve seen requirements and management styles shift from Waterfall to Agile. SPS is especially enticing to me as the advantages of Agile and iterative methodologies have become so apparent on so many projects. Each one of the steps above is tackled by a team in an iterative process and then refined or worked individually. Every team member understands the big picture, and every team member understands how their part fits into the whole. The final product truly is a gestalt.
Structure Problem Solving is a technique I intend to use both personally and professionally to bring clarity of thought and process to non-trivial tasks.
There were two other major highlights of the day. The first was on data visualization. As the actions should be based on logic and facts, they should be natural conclusions of the research. The question always is how can the data be presented with both the least cognitive load and the most clarity—especially when the results are being presented to non-technical people. Several examples of poorly chosen graphics were studied and better options discussed. Of course, the works of Edward Tufte’s The Visual Display of Quantitative Information and Stephen Kosslyn’s Clear and to the Point: 8 Psychological Principles for Compelling PowerPoint Presentations were referenced and highlighted in many ways.
The second major highlight was the time we spent discussing creativity. Some people in the room had practice with structured creativity while the concept was new to others. I have used Brainstorming and Devil’s Advocate approaches effectively for years. The concepts of Brainsteering and Six Thinking Hats were both new to me. The bottom line: creative insight doesn’t happen accidentally. Creative insight happens within the context of intentionally focused thinking.
This course will definitely change my management style for years to come.
Today I met Emory University professor Patrick Noonan at the INFORMS seminar on Essential Practice Skills for High-Impact Analytics Projects. The day included many great gems that will guide some thought processes for years to come, but an early idea was about the new nature of work and that businesses need to “figure it out as we go.” The underlying assumption is that business practices and advancements in data collection and analytics are changing at such a rapid pace that there is really no opportunity to rely on prior techniques. Of course, that’s not universally true—there are many situations where our skills and experiences are directly applicable so that some problems can be solved quickly. However, there are many complex business questions that have never before been answerable as the data and tools required to answer them did not exist. This is new territory.
The bulk of today’s discussion was about decision making processes and how to formulate a plan to answer key questions based on analytics. The advantages and limitations of existing frameworks such as SWOT and SMART were discussed, and how their inherent limitations naturally lead to the use of Issue Trees. What is the Key Question to be asked? Because the first step in the process is always situation specific, this becomes a highly customized process instead of a generic framework. Once the Key Question is agreed upon by key stakeholders, a plan of attack can be developed.
The most interesting exercise today was generating a task list from terminal questions based on the Issue Tree. After formulating the questions, we collectively created Proto-Graphs. I don’t know if Proto-Graphs is a Noonan invented term or borrowed from someplace else. Proto-Graphs are sample layouts of graphs that should be created by the data team to help answer the Key Question. The creation of these Proto-Graphs led to a significant amount of disambiguation. e.g., would a scatter plot or a histogram best represent the data? What time frame should be analyzed? What units are expected? It was surprising to me how many of the “obvious” assumptions were made differently by different team members. The process clarified the result before the expense of creating the graphic with real data was incurred. Another advantage was that our paper sketches were not dependent on the capabilities of any specific tool—our sample visualizations were not guided by what can be done. All of my new data visualization projects will use this technique.
We also discussed how to clarify the Key Question. A highlight of my day was when Professor Noonan asked to use one of my quotes. We were defining ideas to clarify the Key Question and I said that it was essential to ensure that everyone understood the true goal. When asked about this, I replied that “our biggest failures at Blue Ridge Solutions were when we delivered what the client asked for.” What’s that mean? Often in the rush to get something done, business requests are made from a starting assumption of let’s move quickly. Failure to investigate the true goal often leads to the wrong deliverable.
Very excited to be attending this conference in February!
From the conference web page…
Learn practical frameworks and systematic processes for addressing complex, real-world problems and how to facilitate effective action. This intensive hands-on course is developed by the largest organization of analytics professionals, INFORMS.
Started some online work with datacamp this week. The first software I developed was in FORTRAN. Can you believe it? My professor told me to a Mechanical Engineer all software is FORTRAN. I moved to C. Those professors didn’t know what they were missing. c++ quickly became my happy place. And, from my perspective, most modern languages derive so much from that early work.
I can program PHP with my eyes closed. Try it and you’ll see just how tricky that is. Matlab and Mathematica were used frequently in grad school—but it’s been a while. Python seems to be the language of choice for quick data set investigation and integration with AI tools.
Python list comprehensions are cool! That’s one slick line of code to adjust an entire dataset.
phrase = 'List comprehensions are more interesting with numbers'.split()
result = [[w.lower(), len(w)] for w in phrase]
Let the journey begin!
From the DataCamp website…
Learn Data Science from the comfort of your browser, at your own pace with DataCamp’s video tutorials & coding challenges on R, Python, Statistics & more.