Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings

Archives

March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives

 

Thu, 01 Jun 2006

"The Simplest Thing" and the Change Event Horizon

Dan shared an important experience from Expo-C in which he debated Haskell creator Erik Meijer on the XP philosophy of Doing the Simplest Thing That Could Possibly Work. To me, the best part about Dan's story is the realization that our experiences as programmers (and as humans) so powerfully shape the way we approach our work. This explains why a language designer and a custom software consulant would have conflicting software design approaches, and yet both are "correct" in a specific context. We must be attentive our context, particularly when we change working environments. The programmer who thoughtlessly applies a single approach in every context is headed for trouble. Thoughtful programmers consider variables such as the Change Event Horizon when applying the rules they have developed previously:
"So now we had a working definition of 'too simple'. It can be defined as any decision that doesn't consider the scale of the change event horizon. As an agile developer, one of my objectives is to create as small a change event horizon as I can, through the medium of continuous integration, automated testing and regular user feedback."

[/links] permanent link


powered by blosxom