• About PeterSIronwood

petersironwood

~ Finding, formulating and solving life's frustrations.

petersironwood

Tag Archives: tools

I Went in Seeking Clarity

10 Wednesday Dec 2025

Posted by petersironwood in Uncategorized, psychology, creativity, user experience, HCI, AI

≈ Leave a comment

Tags

AI, Artificial Intelligence, coding, parallel programming, problem formulation, problem framing, problem solving, programming, technology, thinking, tools, X10

“I stopped by the bar at 3 A.M.
To seek solace in a bottle or possibly a friend
And I woke up with a headache like my head against a board
Twice as cloudy as I’d been the night before
And I went in seeking clarity” — Lyrics from The Indigo Girls: Closer to Fine

If you think programming is cognitively difficult, try parallel programming. It is generally harder to design, to code, and to debug than its sequential cousin. One of the fun projects I worked on at IBM Research was on the X10 language which was designed to enable parallel programmers to be more productive. Among other things, I fostered community among X10 programmers and used analytic techniques to show that X10 “should be” more productive. Although these analytic techniques are very useful, we also wanted to get some empirical data that the language was, in actuality, more productive. 


Photo by Dominika Greguu0161ovu00e1 on Pexels.com


One part of those empirical studies involved comparing people doing a few parallel programming tasks in X10 to those using a popular competitor. But, like many other “chicken and egg” problems, there were no X10 programmers (other than the inventors and their colleagues). I was part of a team who travelled to Rice University in Houston. The design called for one group to spend a chunk of time learning X10 (perhaps half a day) and another chunk of time coding some problems.

Besides the three behavioral scientists like me who were there to make observations, there were also three high-powered Ph.D. computer scientists present who would teach the language. Programmers tend to be very smart. Parallel programmers tend to be very very smart. People who can invent better languages to do parallel programming? You do the math.



Anyway, after the volunteers students had arrived, one of the main designers of the language began to “teach them” X10. 

But — there was a problem. 

The powerpoint presentation designed to teach the students X10 was far too blurry to read!

Immediately, the three computer scientists tried to issue commands to the projector to put the images in focus. Nothing worked. The three of them began a fascinating problem solving conversation. The conversation concerned what communication protocol(s) among the PC, the projector, and the controller was the likely source of the problem. I suppose it might not have been fascinating to everyone, but it was to me. First, it fascinated me because I was learning something about computer science and communication protocols. Second, it fascinated me because I loved to watch these people think. I suppose many of the advanced computer science students who were in this classroom to learn X10 also found it interesting. Third, I found it fascinating because my dissertation was about human problem solving and I’ve been interested in it ever since.

But the study itself had completely stalled. 

After a few minutes of fascinating conversation that did nothing to focus the images, something possessed me to walk over to the projector and turn the lens by hand. The images were immediately clear and the rest of the experiment continued. 

The three computer scientists had “framed” the problem as a computer science problem and I found the discussion that sprang from that framing to be fascinating. But one of the part-time jobs I had had as an undergraduate was as a “projectionist” at Case-Western, and it was that experience that allowed me to try framing the problem differently. All of us have huge reservoirs of experience outside of our professional “training” and those experiences can sometimes be important sources of alternative ways to frame a problem, issue, or situation.

———————————-

Essays on America: Wednesday 

Essays on America: The Update Problem 

Essays on America: The Stopping Rule

The Invisibility Cloak of Habit

Labelism

Tools of Thought

Where Does Your Loyalty Lie?

Stoned Soup

The First Ring of Empathy

Travels with Sadie: Teamwork

Author Page on Amazon

   

Problem Framing: Good Point!

08 Monday Dec 2025

Posted by petersironwood in AI, America, design rationale, HCI, management, psychology, story, Uncategorized, user experience

≈ Leave a comment

Tags

AI, art, life, politics, problem finding, problem formulation, problem framing, problem solving, technology, thinking, tools, USA

Photo by Pixabay on Pexels.com

You have probably heard variations on this old saw, “To a hammer, everything looks like a nail.” I’ve also heard, “If you have a hammer, everything looks like a nail.” There is also this popular anecdote:

One night, I took my dog out for a walk and I noticed one of my neighbors under a nearby street lamp crawling around on his hands and knees, apparently looking for something. I walked over and asked, “What are you looking for?”

Photo by Photo:N on Pexels.com



“My car keys!” He replied.

I have pretty good vision, so I helped him. I didn’t see any car keys so after a minute or so I asked, “Where exactly did you lose your keys?” 

He stood up, cracked his back, and pointed back to a nearby park. “Over there.”

“Over there?! Then, why are you looking under the street lamp? Why aren’t you looking over at the park entrance?”

“Oh, that’s obvious! The light is so much better here!” 

For a time, I had to very interesting and challenging job in the mid 1980’s at IBM Headquarters to try to get the company to pay more attention to the usability of their products and services. As a part of this, I visited IBM locations throughout the world. At one fabrication plant, our tour guide took us by an inspection station. This was not an inspection statement for chips. It consisted of one person whose job was to look through a microscope and make sure that two silver needles were perfectly aligned.

After we left the station, our tour guide confided that they were strongly considering replacing the person with a machine vision system. The anticipated cost would be substantial, but they hypothesized that the system would be more accurate and faster. It was, our host, insisted, just the nature of humans to be slow and inaccurate.

Maybe. 

When I looked at the inspection station however, with my background in human factors, I had a completely different impression of the situation. The inspector sat on a fixed height stool and had to bend his neck at an absurd angle to look into the microscope. He was trying to align these silver needles against a background that had almost the same hue, brightness and saturation. 

Photo by Wesley Carvalho on Pexels.com

Other than blindfolding the man, I’m not sure what they could have done to make the task more unnecessarily difficult. I suggested, and eventually, they implemented, a few inexpensive ergonomic changes and time and accuracy improved.

Like other companies in the technology segment, IBM often saw problems as ones that could be solved by technology. At that time, technology systems was their main business. Since then, they have expanded more fully into software and services. In fact, those services now include experience design.

If you find yourself enamored of technology in general, or some specific class of technology such as machine vision, speech recognition, or machine learning, you might overlook much simpler and cheaper ways to solve problems or ameliorate situations. Of course, you might lose some revenue doing that, but you can also win long term customer loyalty. 

Even if you are a hammer, everything is not a nail. 

That applies as well to User Experience. You might design the most wonderful UX imaginable for a particular product or service. But if it is shoddily made so that it is error prone; if it lacks important functionality; if the sales force is inept; or if service is horrible, those failures can completely overwhelm all the good work you have done on the UX. Because of the nature of UX, you might learn important knowledge or suggestions for other functions as well. It often requires finesse to have such suggestions taken seriously, but with some thought you can do it. 

During my second stint at IBM, I worked for a time in a field known at that time as “Knowledge Management.” One of our potential clients was a major Pharma company who felt that their researchers should do a better job of sharing knowledge across products. They wanted us to design a “knowledge management system” (by which they meant hardware and software) to improve knowledge sharing. 

Simply building a “Knowledge Management System” would be looking under the streetlamp. They knew how to specify a technology solution from IBM and have it installed.

However — they were unwilling to provide any additional space, time, or incentives for their employees to share knowledge with their colleagues!  

Photo by Chokniti Khongchum on Pexels.com

They were convinced that technology would be the silver bullet, the solution, the answer, the Holy Grail, the magic pill. They viewed technology as less disruptive than it would have been to change employee incentives, or space layout, or give them time to actually learn and use the technology system. 

This reaction to “knowledge management” was not unique. It was common.

To me, this seems very similar to the notion that health problems can all be solved with a magic pill. What do you think? 

—————————————

Since originally writing, we have had the spectacle of DOGE: Destroying Our Government’s Effectiveness under the excuse of making it “more efficient.” It might be (as I strongly suspect) that the destruction was quite intentional. It might be (as some think) that it was accidental. In either case, the result was predictable because the method was guaranteed not to work to actually make things more efficient. If you really wanted to do that, you would take the time to understand a system before trying to redesign it. You would identify all relevant stakeholders and get their input. You would not redesign a system using a gang of young hackers but instead use an interdisciplinary team of experienced experts. You would check out your redesign both with those who were doing the work and with at least one group who were not familiar but had similar experience. Then, on the basis of feedback, you would redesign. When you were sure that you had the design right, you would not then institute it everywhere but in one small trial installation.

There’s a pill for that. 

The Pandemic Anti-Academic.

What about the butter dish? 

The invisibility cloak of habit. 

Process re-engineering comes to Baseball

E-Fishiness in Government

Author Page on Amazon

I Went in Seeking Clarity

16 Saturday Jan 2021

Posted by petersironwood in Uncategorized

≈ 3 Comments

Tags

parallel programming, problem formulation, problem framing, problem solving, programming, thinking, tools, X10

“I stopped by the bar at 3 A.M.
To seek solace in a bottle or possibly a friend
And I woke up with a headache like my head against a board
Twice as cloudy as I’d been the night before
And I went in seeking clarity” — Lyrics from The Indigo Girls: Closer to Fine

If you think programming is cognitively difficult, try parallel programming. It is generally harder to design, to code, and to debug than its sequential cousin. One of the fun projects I worked on at IBM Research was on the X10 language which was designed to enable parallel programmers to be more productive. Among other things, I fostered community among X10 programmers and used analytic techniques to show that X10 “should be” more productive. Although these analytic techniques are very useful, we also wanted to get some empirical data that the language was, in actuality, more productive. 


Photo by Dominika Greguu0161ovu00e1 on Pexels.com


One part of those empirical studies involved comparing people doing a few parallel programming tasks in X10 to those using a popular competitor. But, like many other “chicken and egg” problems, there were no X10 programmers (other than the inventors and their colleagues). I was part of a team who travelled to Rice University in Houston. The design called for one group to spend a chunk of time learning X10 (perhaps half a day) and another chunk of time coding some problems.

Besides the three behavioral scientists like me who were there to make observations, there were also three high-powered Ph.D. computer scientists present who would teach the language. Programmers tend to be very smart. Parallel programmers tend to be very very smart. People who can invent better languages to do parallel programming? You do the math.



Anyway, after the volunteers students had arrived, one of the main designers of the language began to “teach them” X10. 

But — there was a problem. 

The powerpoint presentation designed to teach the students X10 was far too blurry to read!

Immediately, the three computer scientists tried to issue commands to the projector to put the images in focus. Nothing worked. The three of them began a fascinating problem solving conversation about what communication protocol(s) among the PC, the projector, and the controller was the likely source of the problem. I suppose it might not have been fascinating to everyone, but it was to me. First, it fascinated me because I was learning something about computer science and communication protocols. Second, it fascinated me because I loved to watch these people think. I suppose many of the advanced computer science students who were in this classroom to learn X10 also found it interesting. But the study had completely stalled. 

After a few minutes of fascinating conversation that did nothing to focus the images, something possessed me to walk over to the projector and turn the lens by hand. The images were immediately clear and the rest of the experiment continued. 

The three computer scientists had “framed” the problem as a computer science problem and I found the discussion that sprang from that framing to be fascinating. But one of the part-time jobs I had had as an undergraduate was as a “projectionist” at Case-Western, and it was that experience that allowed me to try framing the problem differently. All of us have huge reservoirs of experience outside of our professional “training” and those experiences can sometimes be important sources of alternative ways to frame a problem, issue, or situation.

———————————-

Essays on America: Wednesday 

Essays on America: The Update Problem 

Essays on America: The Stopping Rule

The Invisibility Cloak of Habit

Author Page on Amazon

   

Problem Framing: Good Point!

14 Thursday Jan 2021

Posted by petersironwood in Uncategorized

≈ 3 Comments

Tags

problem finding, problem formulation, problem framing, problem solving, thinking, tools

Photo by Pixabay on Pexels.com

You have probably heard variations on this old saw, “To a hammer, everything looks like a nail.” I’ve also heard, “If you have a hammer, everything looks like a nail.” There is also this popular anecdote:

One night, I took my dog out for a walk and I noticed one of my neighbors under a nearby street lamp crawling around on his hands and knees, apparently looking for something. I walked over and asked, “What are you looking for?”

Photo by Photo:N on Pexels.com



“My car keys!” He replied.

I have pretty good vision, so I helped him. I didn’t see any car keys so after a minute or so I asked, “Where exactly did you lose your keys?” 

He stood up, cracked his back, and pointed back to a nearby park. “Over there.”

“Over there?! Then, why are you looking under the street lamp? Why aren’t you looking over at the park entrance?”

“Oh, that’s obvious! The light is so much better here!” 

For a time, I had to very interesting and challenging job in the mid 1980’s at IBM Headquarters to try to get the company to pay more attention to the usability of their products and services. As a part of this, I visited IBM locations throughout the world. At one fabrication plant, our tour guide took us by an inspection station. This was not an inspection statement for chips. It consisted of one person whose job was to look through a microscope and make sure that two silver needles were perfectly aligned.

After we left the station, our tour guide confided that they were strongly considering replacing the person with a machine vision system. The anticipated cost would be substantial, but they hypothesized that the system would be more accurate and faster. It was, our host, insisted, just the nature of humans to be slow and inaccurate.

Maybe. 

When I looked at the inspection station however, with my background in human factors, I had a completely different impression of the situation. The inspector sat on a fixed height stool and had to bend his neck at an absurd angle to look into the microscope. He was trying to align these silver needles against a background that had almost the same hue, brightness and saturation. 

Photo by Wesley Carvalho on Pexels.com

Other than blindfolding the man, I’m not sure what they could have done to make the task more unnecessarily difficult. I suggested, and eventually, they implemented, a few inexpensive ergonomic changes and time and accuracy improved.

Like other companies in the technology segment, IBM often saw problems as ones that could be solved by technology. At that time, technology systems was their main business. Since then, they have expanded more fully into software and services. In fact, those services now include experience design.

https://www.ibm.com/services/business/experience-design

(NOTE: Since I first published this post, the link above no longer takes you to experience-design but to general consulting services. Too bad.)

If you find yourself enamored of technology in general, or some specific class of technology such as machine vision, speech recognition, or machine learning, you might overlook much simpler and cheaper ways to solve problems or ameliorate situations. Of course, you might lose some revenue doing that, but you can also win long term customer loyalty. 

Even if you are a hammer, everything is not a nail. 

That applies as well to User Experience. You might design the most wonderful UX imaginable for a particular product or service. But if it is shoddily made so that it is error prone; if it lacks important functionality; if the sales force is inept; or if service is horrible, those failures can completely overwhelm all the good work you have done on the UX. Because of the nature of UX, you might learn important knowledge or suggestions for other functions as well. It often requires finesse to have such suggestions taken seriously, but with some thought you can do it. 

During my second stint at IBM, I worked for a time in a field known at that time as “Knowledge Management.” One of our potential clients was a major Pharma company who felt that their researchers should do a better job of sharing knowledge across products. They wanted us to design a “knowledge management system” (by which they meant hardware and software) to improve knowledge sharing. 

Simply building a “Knowledge Management System” would be looking under the streetlamp. They knew how to specify a technology solution from IBM and have it installed.

However — they were unwilling to provide any additional space, time, or incentives for their employees to share knowledge with their colleagues!  

Photo by Chokniti Khongchum on Pexels.com

They were convinced that technology would be the silver bullet, the solution, the answer, the Holy Grail, the magic pill. They viewed technology as less disruptive than it would have been to change employee incentives, or space layout, or give them time to actually learn and use the technology system. 

This reaction to “knowledge management” was not unique. It was common.

To me, this seems very similar to the notion that health problems can all be solved with a magic pill. What do you think? 

—————————————

There’s a pill for that. 

The Pandemic Anti-Academic.

What about the butter dish? 

The invisibility cloak of habit. 

Author Page on Amazon

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • December 2025
  • November 2025
  • October 2025
  • September 2025
  • August 2025
  • July 2025
  • June 2025
  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • July 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • August 2023
  • July 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • May 2015
  • January 2015
  • July 2014
  • January 2014
  • December 2013
  • November 2013

Categories

  • AI
  • America
  • apocalypse
  • cats
  • COVID-19
  • creativity
  • design rationale
  • driverless cars
  • essay
  • family
  • fantasy
  • fiction
  • HCI
  • health
  • management
  • nature
  • pets
  • poetry
  • politics
  • psychology
  • Sadie
  • satire
  • science
  • sports
  • story
  • The Singularity
  • Travel
  • Uncategorized
  • user experience
  • Veritas
  • Walkabout Diaries

Meta

  • Create account
  • Log in

Blog at WordPress.com.

  • Subscribe Subscribed
    • petersironwood
    • Join 664 other subscribers
    • Already have a WordPress.com account? Log in now.
    • petersironwood
    • Subscribe Subscribed
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...