I am engaged in a project at work where I am unraveling someone else's code and knitting it back together in a fashion where it will be much easier to trace through the bits of yarn when I'm done. Unfortunately, it's not trivial in any sense.

But I am making progress.

Slowly. Very slowly.

I actually don't so much mind refactoring code, as long as I am doing something that will improve the code base. For instance, today I worked with one of my colleagues to convert a reference to a particular class to a reference to a shared interface implementation. This was good, because now anyone else who has the same problem will be able to implement the method on the interface and get the behavior that they want.

And then there is the refactoring that is just cleaning up after other people who have introduced references to other libraries in classes that simply shouldn't be using those libraries. This is much *less* fun.

At least the end is in sight.

Another round of fixes destined for an emergency patch that I spent most of the day hacking out with one of my co-workers. The code in the neighborhood is much cleaner now -- I wrote this fairly early in my Java adventure and was able to make a bunch of fairly trivial, but major improvements while cleaning up the bad behavior that was going on. And I managed to eliminate a lot of duplicate code, which is always a bonus.

It's passed our initial smoke tests to see if it has fixed all of the client bugs, so a build is underway and QE will have at it in the morning.

Chaos! It's what's for lunch.

And today was back to work (and school) after a two-week break. There were varying degrees of success.

On the other hand, I finally threw up my hands and stopped trying to add a remove method to my Java iterator built on top of my unifying interface layer. Instead, I've coded things using a different approach to what I'm doing.

I've managed to cobble together a first unit test to throw against the wall that found a couple of different (and one pre-existing) bugs and have fixed those. Now that the framework's in place, I should be able to write a lot more test cases fairly quickly to make sure that there aren't more bugs or, if there are, that I can fix them. :)

I have become fond of unit testing...

I may be getting tired of the bugs coming in, but apparently they are not tired of me.

Ah, well. I was able to patch things around so that I could read the seriously damaged file I was sent this morning. Now if only the rest of the code would behave itself... :)

I have been fixing a silly number of bugs in the last couple of days.

One of the bugs that I am fixing right now is one that I thought was going to be a horrible amount of work. It turns out that I can fix it rather simply, which I found out after digging through the code.

I just can't *test* the fix, for reasons having to do with Microsoft Excel's lousy handling of COM memory and garbage collection in .NET.

So I am checking in the fix and passing it along to someone who has installed the 32-bit version of Excel, which seems to do a better job of garbage collection than the 64-bit version. That's not what I would have expected, but it is what appears to be true.

Some problems are just annoying.

I am still crawling through our user-interface code. I have cleaned up a great many things, but there are some interactions that are perplexing me. I think I have some ideas about how to proceed, but I'd like to talk with one of the fellows who wrote it.

I'd like to give it back to him, actually. We'll see how that goes. :)

I have fixed a great many bugs this week.

Right now, I'm looking at the debris in our Visual Studio 2019 port. The COM handling machinery there seems a bit idiosyncratic, but it's possible to work around those eccentricities once you find them. I'm doing bulk corrections and it seems to be stable.

But I've found some code in our UI layer that I really don't like. I think I can fix it in a day and then we'll see if some of the idiosyncrasies in *our* code will be good enough to go away.

I am trying to write a new bit of code to make a particular interface work, but the code that I write isn't working (or apparently called) even though it seems to have all of the necessary elements for this particular incantation.

I am annoyed.

I'll try this again tomorrow.

I cleaned up a bunch of crufty, slow code in our user interface layer over the last week and checked the changes in today. There are still some more places that can be cleaned up, but I took care of a lot of the low-hanging fruit.

I rewrote a lot of our XML handling code in C++ to be more efficient.

Unfortunately, I appear to have made a mistake somewhere, because I'm getting an error message from the COM object that is consuming the results. Sadly, it is not a very helpful error message.

At least to me.

I have asked for help from the folks who wrote the COM object. We'll see how it goes.

Don't Write Inefficient Code.

This suggests, perhaps, that I have watched too many episodes of "Don't" during the pandemic. However, I spent the afternoon cleaning up some really inefficient code in one of our modules this afternoon. I'm not sure exactly how much impact it will have -- we'll know more about that when it gets into testing.

But it will help. I had explained much earlier how to make at least some of these fixes. They were never made.

Until now.

Don't. Write. Inefficient. Code.

*sigh*

Three day weekend over, so it's time to be back at work.

I made some progress today (and cleaned up a few lines of questionable code in my own area, just so you understand that I make mistakes). Unfortunately, a lot of the other stuff that I was looking at needs some refactoring, which turns it from "fix a bug" into "this is a project".

I do not need another project right now, especially in code that I'm not that conversant with.

We'll see how it goes.

This afternoon was spent refactoring someone else's code. I think it's helped, but I need to find out where the other bottlenecks are hiding. Maybe they'll turn up tomorrow.

I am jammed up waiting for things on my various projects, so I went to fix SpotBugs errors today in between meetings. I fixed about 10% of the outstanding warnings, although half of that total was in a single file and fixed with a global search and replace.

Even so, it's progress.

It's hard to code review a merge between two branches that changes as many files as this one does.

It *looks* ok.

At work today, I set out to fix a bug on my bug list. While I was working on it, I found a small bug that was preventing me from testing the fix, so I fixed that. I also found two other annoying bugs that I wrote up as new bugs for the appropriate people to fix.

Net bug score: one bug removed from the list, one other bug fixed without ever hitting the list, two bugs added to the list. bugCount = +1, although xBugCount (which is a more accurate version of the statistic) is 0.

No wonder we never catch up. :)

I checked in a new set of APIs at work that substantially clean things up in the project that I'm working on.

Sadly, they are -- unsurprisingly! -- not at all compatible with the old APIs that someone else on the team wrote. This will mean a certain amount of retrofitting is required.

But when it is done, it will be better.

For someone who doesn't actually know C#, the port of this chunk of my code from Java to C# is going quite well. I think that I'm likely to finish the whole thing up tomorrow unless something goes horribly wrong.

The biggest chunk of time was spent sorting out the differences between a Java iterator and a C# IEnumerable interface. Other than that and a few scoping issues, things are going pretty well.

We'll see what happens next. :)

I decided to take some time this afternoon and take a look at the warnings that the static analysis tool in Visual Studio is throwing for one of our C# modules. Most of them are harmless, although some of the (mostly) harmless ones are worth fixing. Some worry me and they are *definitely* getting fixed.

And then I'll test this thing and make sure that it is behaving. :)

I have patched the Polish language into the C++ code (as patching localized languages into the C++ code is complex), while I have patched all of the new languages into the C# code. The rest of the work on the C++ side is being left as an exercise for another programmer. I was, however, kind enough to write documentation telling how to do it. :)

I am back to work and -- in and around a lot of meetings -- am continuing my spelunking expedition through some code that I am fixing up. After sufficient inspection of a routine, I can usually remember what it is *supposed* to do. Then I need to see if it's actually *doing* that. And then I need to make it work with the changes that I'm making. All this is very entertaining. And just a bit exhausting.

Today, I stared at three complicated if statements and the code within and rearranged them so that there was slightly more code and fewer if statements. It is remarkable how much more clear the code became. It's still not quite *right*, but I have written comments to indicate what the code is *supposed* to do and -- after I get done with it tomorrow -- that is what it will be *doing*.

This is *way* more work than it should be.

So I'm working on a project at work where I'm porting some more C++ code to Java. I looked at the original code and said, "Well, let's see if we can streamline that." And I wrote a set of classes to support the behaviors that I wanted and which would generate the XML that I needed that C++ had been handling by writing exquisitely hand-crafted XML.

And I looked at the classes and said, "That could be simpler." And so I refactored the class structure I had written.

And I looked at the classes and said, "That could really be simpler." And I refactored the class structure into a set of Java enums.

It's a lot simpler now. :)

Oh, it *does* look like I solved the problem at work yesterday.

Today, I took a few minutes and deleted the fossil code from the old version of the project that I'm working on. The file went from 2900 lines to 900 lines. So the new code is less than half the length of the old code. Of course, I *did* push a couple of things out to other classes, but even so, it's substantially cleaned up.

I have almost solved the various problems at work that are keeping my new code from working properly. I *think* that one of the failed attempts managed to leave some flags set that prevent the calcs from executing, so I am now *clearing* those flags to see if that fixes the last problem.

I hope it does, because otherwise, I am running short on ideas.

Mind you, I *saw* that one of those flags was set while watching in the debugger, so I am reasonably optimistic that I have found a problem.

The question is: Have I found *the* problem?

We'll see.