Hey there! How was your weekend? Ready for another week full of opportunities?

I had an amazing discussion with my colleague Gonçalo, today. We discussed when to be proactive and when to be reactive when it comes to software maintenance. I’m all about proactiveness. He was a little of both.

My arguments were that, if we detected a situation that still isn’t a big problem, we should always plan to implement the necessary solution to avoid it becoming a big problem. He mostly agreed but said that when working on a business, the primary objective is to deliver value to the customer, to allow for the company to capture more investment and, when there’s a little more time, or the problem starts to really bit our asses, then it’s when it’s addressed.

He continued his arguments, saying that while some situations require immediate (sometimes urgent) attention, there’re others that can be dealt somewhere in the future, when there’s time to do it properly. With this said, he was more inclined to be more reactive while keeping an eye to the situations that could potentially escalate to real problems.

Interesting ten minutes of discussion. The conclusion is that we can’t be black and white when it comes to decisions that not only affect the product but also affect the business and, so, must be moderated and strategically planned. I understand, and respect, Gonçalo’s thinking, agree to some extent, too, and accept that’s a consequence of doing business, but I know that this only means that the situations will only be dealt when there’s really no more options available (aka, to little to late).

I, however, stand by my initial arguments.

To avoid real problems down the road, one must handle the situations as soon as they appear. That’s why I develop with a TDD approach, for example. The time I spend creating the tests, now, will save me time, tomorrow, by keeping me away from potential regression bugs.

Speaking of time and TDD, I continued developing the report class and I, finally, was able to let Ricardo access my current work branch and go ahead with the part of the integration he’s been waiting to do. This taks was not planned to take this long, but we all know there’s work that we think it’s going to be a relatively simple one, and then, only when you’re working on it, is when you notice that it’s more complicated than expected.

I must admit that a great part of the time invested was me creating missing factory classes and developing the necessary unit and feature tests, as well as being the first time I’m really digging in the domain logic. I’m confident that, event knowing that the Sprint ends this Thursday, I’ll be able to finish it on time. 🤞