Sophometrics — web log (ideas)

 

Web entry — November 28, 2012

“Design Process — THUNK”

At a design-centered meeting in Phoenix, early in 2010, I offered a new description for a THUNK.

But, just a moment. Why should you care about THUNKs — or design process? Getting new things done, and changing the way we do old things, is becoming more difficult. The very nature of commercial activity, combined with growing environmental and political pressures, drives us toward complex circumstances. We need better tools to help us solve difficult problems. So, back to my description.

My initial impression of the word THUNK was similar to this (found at Wikipedia):

Thunk (functional programming), a piece of code to perform a delayed computation (similar to a closure).

I assumed (many years ago) that a THUNK must include a "smart" bit of information (in the piece of code) and that information could help solve a difficult problem. This bit of information must wait for additional information so that the sum of these parts could provide a solution (i.e., a useful result).

The meaning I assign to THUNK — in the context of design process — relates to wrapping up a collection of knowledge (research results, information, discussion in progress, raw ideas, and potential solutions) into a package — the THUNK. Then, sometimes sooner, sometimes later, one of two things might happen. Either one participant will settle on a solution, or new information plus information in the THUNK will help the team solve the problem.

I believe it is typical for humans, when working on difficult problems, to notice new sources of information that went unnoticed before. Creating a THUNK can alert designers to this new information.

So ------ I have imposed on a software engineer's meaning of THUNK, but this is what I was driving at in Phoenix. A THUNK (the idea, not the word) is one of the tools used to solve difficult problems effectively.

 

Web entry — June 26, 2012

“Cycles in Formal Design Analysis”

This entry concerns the application of reliability analysis vis-a-vis numerical analysis, to the design of critical facilities. Specifically, this entry identifies a cycle describing an industry approach normalized for data center design. It seems the critical facility industry is traversing this cycle:

 (1) Identify new design problems stemming from new demands on data centers related to the .com boom (circa 1997 ...).

 (2) Look for reliable patterns in the physical infrastructure, testing proposed patterns against formal numerical analysis (circa 1999 ...).

 (3) Copy successful patterns across various projects, until the industry has a “standard” set of solutions (from 2000 to 2008).

 (4) Learn how to measure and operate these facilities for better reliability (from 2002 to 2010).

 (5 / 1) Identify new design problems, this time due to the modular nature and scale of cloud computing solutions (circa 2008 ...).

 (6 / 2) Look for reliable patterns in physical infrastructure ...

The difficulty I see in the moment, is that the industry is not returning to numerical analysis quite yet. I expect that this will be identified as a problem shortly.

Cycles, yes?