I'm working on a side project at the moment, just a clean-up for an old customer who was acquired and needs to be migrated off our old systems and onto their parent company's systems. To do that, we need to make a single, simple calculation. About half of the time so far in the project has been taken up by trying to extract the core of this calculation from the legacy system in which it was written. By comparison, the same basic function for the "new" parts of the system was a few lines of code, since the new system is anal about storing every little bit of metadata about the things it does.
You often run into these situations in working with really large, really legacy codebases. The code has acreted rules and requirements over the years, none of them really spelled out. Some relatively simple operation is now pretty much inextricably linked into the overall functioning of the system. Poor compartmentalization of the legacy code means that side-effects happen all over the database and the code-base.
They are a PITA, you often wind up trying to whittle down the old system's code so that you can run some subset of the system as a separate process and munge the data, but you're always thinking "maybe I could just implement it in a few lines of code" in the back of your mind. You're pretty sure that if there was a proper spec you could... but there isn't... and it took years to acrete all the rules and exceptions in there... better to just hold your nose and try to make the best of it.
Comments
2010-08-31 12:04
That template db idea is prett y neat. I have to say it's get ting pretty annoying downloadi ng database backups and [...]
2010-08-23 20:57
Yeah, in a similar boat with t he code I write... upshot, I'v e got some pretty good compat code in snakeoil, just w [...]
2010-08-22 08:40
Yeah, that's what I started do ing (the function to convert t o bytes), as I support down to 2.4. Thing is this is [...]
2010-08-22 06:28
Your blog aparently likes does n't handle the less than char (<) conversion all that wel l.. everything following [...]
2010-08-22 06:24
The annoying thing about suppo rting both py2k and py3k is th at you wind up having to get r ather explicit about you [...]
2010-08-16 00:48
The measure of a man, I have a lways thought, was - that he l oved. And was loved.
2010-08-15 21:28
Hmm, hadn't realized that was what dpush was for. I guess I 'll have to make the trunk a b ranch rather than a chec [...]
2010-08-15 20:43
For what it's worth, newer ver sions of bzr-svn will not remo ve existing revisions from you r mainline unless you ex [...]
2010-08-15 20:40
bzr-svn supports not inserting any unusual revision properti es, it just means that pushing your bzr revisions into [...]
2010-08-15 18:21
Hmm, maybe I missed something there. Do you mean merge supp ort as in being able to pull f rom N branches into your [...]
2010-08-15 17:45
Lack of merge support kills th e main benefit of bzr-svn over just using svk I'd argue. Personally, I'm *extreme [...]
2010-08-15 11:46
You might want to check out hg subversion
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.