InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Programming Processes

Posted by Kurt Christensen on Aug 03, 2008

Sections
Process & Practices
Topics
Change ,
Agile ,
Adopting Agile
In "The Secret Curse of Expert Archers", New York Times columnist Katie Thomas describes the strange affliction known as "target panic", which causes world-class archers to inexplicably lose the ability to control when they release an arrow at a target. While usually regarded as a psychological problem, new research indicates that target panic may actually be a neurological disorder.

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.
  • This article is part of a featured topic series on Agile
Talk on how the mirror box works by Steven Devijver Posted
Re: Talk on how the mirror box works by Kurt Christensen Posted
Re: Talk on how the mirror box works by Steven Devijver Posted
  1. Back to top

    Talk on how the mirror box works

    by Steven Devijver

    www.ted.com/index.php/talks/vilayanur_ramachand...



    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.

  2. Back to top

    Re: Talk on how the mirror box works

    by Kurt Christensen

    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.

  3. Back to top

    Re: Talk on how the mirror box works

    by Steven Devijver

    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.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.