raganwald
Monday, July 25, 2005
  Heresies, Episode I
Dear reader, you are an intelligent person. So I'm going to save us both some time and skip several paragraphs where I regurgitate what consultants and books on creativity have said for decades, namely that there's a benefit to thinking about things that might be very, very wrong.
Though the wind is not made by leaves flapping, as some children guess, the theory is sufficiently profound that it should not be dismissed out of hand. In fact, disassembling erroneous concepts is one of the best ways to find new ideas.
Nicholas Negroponte, Creating a Culture of Ideas
I'll also skip the part where I list the number of things that were known to be very, very wrong and turned out to be right.
The statements that make people mad are the ones they worry might be believed. I suspect the statements that make people maddest are those they worry might be true.
Paul Graham, What You Can't Say
And so after taking several paragraphs bragging about how much writing I was going to skip, here are the ground rules for this little creativity game:
  1. Find the extremes. We're interested in the outliers, the data points and ideas that live in the fringe. If somebody says that Extreme Programming works in 98% of the organizations that adopted all of its practices for a complete project, forget about what those 98% can teach us. Don't even argue with the number 98%. But those 2% that still failed... What's up with that?
  2. Play the ball, not the (wo)man. Disregard the author of any source I quote. This works both ways: if you respect the author, don't forget they may be wrong. Or right. Or it doesn't matter, because the benefit is in thinking about the idea, not patting yourself on the back for agreeing with or disagreeing with someone else. And this is really the same point: Popularity is irrelevant. Disregard whether an idea is popular. You may be suspicious of anything popular. Let go of that. Again, the benefit is in thinking about the idea, not patting yourself on the back for agreeing with or disagreeing with someone else.
  3. And finally... create extremes. Become a reductionist. Embrace the Tar Pit. Reject postmodernism. Look at an idea. Take one element of it, right or wrong, good or bad. Preferably wrong (see above). Ask yourself: "if this were not just true, but universally applicable, what would that mean?"
Ok, so here is the first heresy: software architecture sucks wind. Or blows chunks. It's resume-driven design.
What do you think?

Labels:

 

Comments on “Heresies, Episode I:
How about: 'Frameworks are useful because they place a structure on you so that later developers will easily be able to understand your application' I've yet to see two Struts apps that even remotely resemble one another...
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /