Behavioral Economics and Code

One of the things that I find most fascinating about software development is the gulf between what we think we do and what we really do.  I think that software developers, more than most other professionals, are prone to seeing themselves as "rational actors."  We plan, we design, we write code and therefore we have code -- good clean code that is supple, easy to change, and perfectly tuned to what we need it to do. 

Right.

The thing that we forget is that we are human.  We have quirks.  And, some of the quirks significantly impact what we produce.  

When I've been speaking at conferences recently, I've been asking the following question: Is it easier to add a method to a system or to add code to an existing method?  A special bonus points followup question: Is it easier to add a class to an existing system or to add code to an existing class?

Frankly, I don't care what the people's answers are when I ask those questions, but I feel that we can figure out the answer just by looking at the code that is typical in the industry.  Many projects have quite a few very large methods and very large classes.  In those cases, it was easier to add code to existing structures.

We can go back and forth about why this is the case.  My theory is that it isn't the physical act of creating new methods and classes, it's the act of naming.  Naming can be rather hard -- just hard enough to try to avoid sometimes.  And, well, that could partially explain what we are confronted with.

I don't know what the answer is, but I do know that there might be an alternative to "try harder."  To see it, we probably need to develop a much keener sense of how situation alters behavior in development.  Something with a basis closer to what Cass R. Sunstein outlined in the book 'Nudge'.

 

Note: I'll be teaching the first public Brutal Refactoring course in Oslo on Jan 21-22nd, 2013.

 

Comments

[Jason Gorman]

Module Gravity Well! :)

[Dclinton]

A quote I came across a while back (sorry, I can't recall who said it) is "There are only two difficult problems in software development - cache invalidation and naming things".

For me, one of the biggest productivity boosts in a development environment is the ability to easily re-name things. This stops me from spending too much time up-front trying to decide on the ideal name for something, knowing that I can change it easily as the code progresses and I understand the concept I am trying to express more clearly.

[George Paci]

The version of the quote I heard was:

There are only two difficult problems in software engineering: cache invalidation, naming things, and off-by-one errors.

[Rimichelangelo]

A smart post, on this subject, is suggesting an analogy with physics:
http://www.carlopescio.com/2008/12/notes-on-software-design-chapter-2-mass.html