Neurologists are beginning to look to processes deep inside the brain in order to understand afflictions which have previously gone unexplained. For example, in a recent article for The New Yorker, Dr. Atul Gawande describes a new treatment for "phantom limb pain" - the acute pain felt by amputees in arms or legs which do not exist. A doctor places an amputee in front of mirrors which create the illusion of a full set of limbs, and then has the patient perform a variety of tasks - for example, conducting an imaginary orchestra. A new study from researchers at Walter Reed Hospital shows this "mirror box therapy" to be remarkably effective in treating phantom limb pain. Astoundingly, it appears that providing a new and unexpected set of sensory inputs to the brain modifies the processes within the brain by which those inputs are handled.
Of course, in the world of artificial intelligence, there's nothing astounding about the idea of using data to modify the algorithms which operate on that data - such "learning algorithms" are used in applications ranging from speech recognition to credit card fraud detection. In fact, as it becomes possible to work with increasingly large data sets, it would appear that the data given to most learning algorithms is more important than the algorithms themselves. In a presentation given at Startup School 2008, Peter Norvig described the performance difference between five self-modifying learning algorithms for natural language processing, and showed that the performance improvements gained by selecting a better algorithm are rarely as great as the performance improvements to be had by simply processing more data.
But could this be a metaphor for the process of developing software? In the book "Metaphors We Live By", George Lakoff and Mark Johnson describe how metaphors shape understanding, and the ways in which metaphors simultaneously reveal and obfuscate the world around us. For the brain, and for software, and for software development, the dominant metaphor is that of a machine - in other words, hardware. But in both cases, better progress might be had by instead viewing processes as software - programmable; prone to error, but easy to fix. If software is to be the metaphor for software development, then software development processes should be created and refined in the same way as software should be created and refined - loosely at first, building only as much as needed, and always iteratively and test-driven.
Although it can be frightening to abandon the idea of prescriptively defining optimal processes, the reality which seems most consistent with both the human brain and with software itself is that the best way to build a software development process for a particular group of people is to forget about process definition and focus on process evolution.
Talk on how the mirror box works
Otherwise I don't see how this or "target panic" have anything to do with software development. I think metaphors are a pretty ineffective in controlling any human activities. With regards to any process, I think the fundamental understanding that people will ultimately decide how the process works is quintessential. Everything else is a consequence of this very simple understanding.
Re: Talk on how the mirror box works
I completely agree that many things derive from the fact that software development processes are created by, affect and serve human being, but my point was that for any process, we should be less concerned about correct up-front definition, and more geared towards ensuring that the processes are able to evolve in response to input, and the more input the better.
Re: Talk on how the mirror box works
Well, the thread I was trying to make is that process is evolutionary, modifying itself based on the inputs received, and that this seems to be universally true in different contexts - the brain, software, and software development. I completely agree that many things derive from the fact that software development processes are created by, affect and serve human being, but my point was that for any process, we should be less concerned about correct up-front definition, and more geared towards ensuring that the processes are able to evolve in response to input, and the more input the better.
"processes are able to evolve" sounds like processes have the ability to evolve by themselves. I would advise you to take the brain and by extension humans and thinking about everything else in a different way.
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014