In my brief flirtation with Psychology in my first year of university, I learned more than I’d ever want to know about rats in a maze. My distaste for the exercise would come back to haunt me last year when my stepson needed a dwarf hamster for his science project. Wendy is now a part of the family. You can see Wendy and our home-made maze on the right.
You’ve no doubt seen the images I’m talking about. You put a piece of cheese that the mouse or hamster loves at one end of the maze and you drop him (or her) in at the other end and time them over and over and over and over again running through the maze to see if they can learn how to get to the cheese more quickly by avoiding wrong turns.
Then, when you know the poor animal has learned perfectly where the cheese is, you remove it.
The mouse or hamster will go back down that tunnel over and over again, certain that the cheese will be there next time.
The difference between humans and hamsters is that eventually the hamsters will quit.
We humans are, as a species, obstinate. If we think there’s a favorable result down that maze somewhere, we’ll keep going until we starve to death.
I’ve had a couple of projects that have been in this category for some time. One project involves the link with a piece of software from a vendor that we’ve worked with for decades. Some time ago, they released a new version of their software and suddenly the link we’d counted on for ages didn’t work properly. We asked the vendor if they knew what we should do and they didn’t and the developers who have worked on this have made a number of attempts to solve the broken link.
The problem is, that despite being brilliant developers (much smarter than myself), they have focused over and over on the one bit of code that throws an error. We know that error very well by now and no matter how many times we look at that one tiny bit of code, it won’t work. Oh they’ve tried getting to the reluctant command in different ways, some of them very clever but we’re still at a standstill. It’s the cheese-less tunnel for us.
This week I put the challenging project back on the books and told the staff to throw out all the legacy code for the module.
“Start from a blank page,” I said. “Your job is not to make that code work. We threw out the code. Your job is to solve our basic business challenge as though looking at it for the first time.”
The thinking on the project has already changed. Instead of working on the one command from this vendor’s product that isn’t working, we’re looking at all paths of movement of data from our system to theirs that results with data in the right place. It turns out there are quite a number of options which we’d never tried.
It’s not unusual in a project to head down one path, hit some barrier and then pause while you wait for the barrier to be resolved but the lesson for me in this project is that you can wait at a barrier too long before it makes more sense to back up and try some other route. In this case, closing down the path we’d been on for so long is forcing the developers to rethink the entire exercise laterally instead of literally.
I don’t actually care what the path to success is so long as we get there. That a particular method fails is less interesting to me than the end result of solving the business problem I started with.
Over the last few attempts, we’ve had reactions from our staff that want to place the blame on the other vendor, or the indignation that their software doesn’t work as documented or on the righteousness of our approach.
None of those gets us the cheese.
I’m quite optimistic now that we’ll finally solve this particular challenge. I’ll keep you all posted on our results.