When do you cut your Losses?

I was getting frustrated. I thought it would be a simple tweak to add this check to an existing test. All I wanted to do was duplicate an object use it in two different places and make sure the display name was the same in both of them and then delete it.  It should have been quick and easy –  15 minutes at the most, so why was I still working on it four hours later?

It was time to retrospect (well ok – it was past time to retrospect.)  What had gone wrong? Why was I in this situation and how could I avoid being here again in the future?

What I had thought would be a simple tweak to an existing tests turned out to be much more complicated.  When I added it in, the application started crashing during the test run.  “Oh I’ve found a bug.”  But no, when I tried to reproduce it outside of the test system, there was no crash to be seen.  I tried various things and asked some questions and we think we know why this is happening (due to some internal counter getting confused and due to some difference in the way we pass around certain types of errors in the test and live systems).  I was able to figure out a way to add the check to the test, but it had take 4 hours instead of 15 minutes.  Was it worth it?  Was it worth spending that much time on adding a simple little check to a test?

Good – I learned something about the system

Those numbers logged in that object?  Yeah, they mean something, and yes they are magic numbers and yes this area of code is not very well written.  I did learn some important and useful things about this area of the code including that we don’t understand this area very well.

Bad – Four hours is a long time to do what I was doing

The actual check I put in is pretty low value.  It is unlikely that we will fail in this way again as we are checking something that was just fixed.  The only reason I was adding the check in the first place was that I had thought it would be very low cost to do so. Adding something that is low in value is ok if the cost is also low.  Adding something low in value when it takes half my day to do so is not the best use of my time.

On the balance – I shouldn’t have spent this much time

Looking back on it, the time spent for the value gained was not worth it.  Even if you add up the value of the check I added along with the value of the things I learned, I still don’t think it was worth it.  You can always salvage a situation though and that can perhaps be done here by learning how to not repeat this.  What could I have done to realize that it was time to cut my losses? What would have been a better way to approach this situation?

Two Possible Options

Option one is to set a time limit for ‘low value’ stuff like this.  I could have said before starting that this check isn’t very high value and so I won’t spend more than half an hour or an hour working on it.  That probably wouldn’t have worked very well in this case though because I was running into what I thought was a defect (and to be honest kind of is, but just not one we will fix), and so the time that was I spent was mostly on trying to track down the bug.

Option two is to use this as an opportunity to leverage some high value work out of the time.  Part of the reason it took so long was that the test I was added this check to wasn’t the easiest test to debug and I don’t have a system in place for easily figuring out what to do when there are differences between the test system and the ‘live’ system. I didn’t take this approach, but in the future if I run into a similar situation again I will try to use the opportunity to overload what I am doing.

Cut your Losses

So when do you cut your losses? I’m not exactly sure yet, but I think one other thing that needs to be kept in mind is that if something is taking much much longer than originally planned or intended, it needs to trigger a response to stop and think about what is going on.  Am I still solving the same problem?  Is this problem still worth solving?  Should I cut my losses and go?  Should I double down and overload the process to still gain value out of what I’m doing?

We humans have a bias known as the sunk cost fallacy and so it is very easy to get sucked into the vertex of spending more time on something just because we have already put time into it, but sometimes the fastest way forwards is backwards.  If we are digging ourselves into a hole, more digging isn’t going to get us out.  It might be time to stop and start building ladders instead.

Lesson learned:  retrospection is helpful and if I find myself in a time overrun situation for a given task, I should stop to retrospect sooner rather than later!