threaded process
had to dust off some old code that hadn't been used in about 9 months.
the programmer who wrote the code left the company about 5 months ago.
it involved a process that involved a long list of addresses. the list was split into several small lists, each assigned to a process that divided up the work. this normally is a neat trick, but in this case it didn't make a difference because of an outside dependency that forced us to deliberately slow the whole process down, lest we be shut off.
i'm not sure why that was there in the first place. probably put in before we knew about the dependency.
anyway, that part of the application had some bugs which caused certain addresses to be processed twice. who knows why?
this difficult-to-troubleshoot problem was quickly resolved just by ripping out all that complex concurrency crap and doing it in a single thread. took about an hour to make sure everything was clean, but you know what? when i was done, the process was much easier to follow and worked great.
so my programming lesson of the day was a real-world example of something I already knew in principle: the simple solution is usually the better one.
