Paradise ponders: good neighbors and bad code edition...

Paradise ponders: good neighbors and bad code edition...  Yesterday was a bit of an odd day for me.

I started out by helping my friend Tim D. moving his hand line.  It was the fifth day of a six day watering cycle, so we'd been doing for several days already.  The work isn't really very hard as the pipes only weigh 35 or 40 pounds – but it does involve a lot of walking.  I'd guess we walk a mile to a mile-and-a-half each morning we're moving pipe.  After finishing with the pipe, I came back inside for a second cup of tea.

As I was drinking that, I noticed our newest neighbor, Heath C., out on his field with his truck and trailer.  He was picking up the 140 bales of hay that he'd had baled the day before.  That's a lot for one guy to pick up, especially when he has to keep moving his truck to somewhere near some bales on the field (after picking up the nearby ones).  So after I poured the tea down my gullet I wandered over to give him a hand.  Shortly after I arrived, a young lady (Sarah S., fifteen years old) also came out to help.  Between the three of us we had that field picked up, the bales stacked, and tarps thrown over to cover them in under an hour.

By the time I'd finished with all that, I was physically wiped out.  My ancient body isn't used to doing hard physical labor like that! :)  With what little energy I had left, in between helping Debbie with some cleaning, I fixed a piece of bad code in the irrigation supervisor program I'm working on.  That bad code was small, but way too complicated and “clever”.  When I realized that I was having trouble making it work correctly because I had trouble understanding what was going on in it, I knew it was time to start over.  I changed the design to an event-driven finite state machine.  That ended up being perhaps four times as much code, but ... it all worked on the first try.  Even better, as I tested it and discovered additions that were needed, those were all easy to make.  Repeatedly in my software development career I've bumped into situations where state machines were great solutions – but nearly always it's the second or third approach I take.  For some reason I seem to have trouble recognizing early the problems that would make good use of state machines...

In my last employment, on the few occasions when I made a state machine to solve some problem, I got quite a bit of criticism from other engineers if they noticed what I'd done.  Their issue was, basically, that they didn't understand state machines and therefore my code was hard for them to understand.  Though I debated them heatedly on this point, in all cases but one my boss eventually told me to remove the state machine.  That one exception was a particularly complex case where nobody could come up with a viable alternative. :)