Saturday, April 17, 2010

thinking about thinking

Despite my best intentions, I've neglected this blog.  I've been spending whatever spare time I've had on my other non-techie blogs and frankly haven't been taken with anything on the technology front that's inspired me much lately.  

One thing I've noticed that certainly isn't inspiring has nonetheless been on my mind lately: thinking, or rather the lack of it.  It  has been an unfortunate constant to greater or lesser degree over the quarter century I've been making a living writing software: we too often as both developers and managers forget to include in time estimations what might well be the most important thing: time to think.

Estimates might include the time it takes to "design" (usually, the time to type up the design or sketch it out), the time to type in the code and tests, time to debug, refactor, adjust, and time for documentation (user doc, examples, etc.).  Each of these activities as described are necessary things but are in the end essentially documenting the results of thinking.  The code documents your thinking so that the machine understands and can execute it, the debugger helps you figure out where your thinking has gone wrong (so do, obviously, your tests).  It seems to me, though, that the actual thinking itself is never raised as a formal activity.  Ideally, it shouldn't need to be (it should be assumed as the primary driver for everything else).  But in my experience that isn't always the case. All the rote things you have to do take time as well, and often if something doesn't fit into that vein, it's not considered.  Of course, you still have to do the thinking, but because no time has been allocated for it, it often gets rushed and relegated to a supporting part where it really ought to be the star.  Maybe it's just me, but I have a feeling in this case, it's not.

Of course, this malady has been noted over the years by a number of folks.  Check out Andy Hunt's Pragmatic Thinking and Learning for a great read that touches on this (among many other things).

1 comment:

  1. The thinker need reserve time for his thought and yet providing this level of detail to the boss man or lady seems entirely wrong-headed to me.

    I know the analogy of software developer to plumber, electrician, etc or any of the other skilled trades is a hackneyed one, but think about how they quote their work: time and materials. Now arguably the think time required to install a kitchen sink is likely a smaller percentage of the actual time spent laboring, and yet no clear division is made in the bill.

    All that said, couldn't agree more that there is a distinct absence of thought put into much of the code I've read and had the displeasure of maintaining over the years. And, more often than not, when the thought was put into it, sadly the ability of the thinker to translate thought into deed was not always so exceptional.