Monthly Archives: August 2016

Bi-temporal foreign keys support – reloaded

Since I’ve started my new job at the Braviant Holding, I could not find time to continue working on our bi-temporal project. And it was really sad, but to be honest I didn’t feel like I have a single brain cell left to do anything except work.

And I cant’ tell that my today’s life is less stressful than it was for the past four months, but I for some reason about a week ago I’ve resumed that work. It was very difficult to recover details of what I was doing  almost six months ago, and why I didn’t  finish some functions, and so on; especially because I’ve move to a new laptop in between, so all of the intermediate testing, “not worth saving in the git repo” was also gone…

Long story short – today I’ve completed the generator of the functions, which will be used validate bi-temporal foreign key constraints. Than was one of the most complicated pieces of code I’ve written for this project.  But although this is the most difficult part, it’s not the only thing which is necessary for full bi-temporal integrity constraint support. The good par is, that I know exactly what should be done!

Advertisements

Leave a comment

Filed under research, Systems

New vs old: should we even validate?

I think that there is no developer in the world who never had to face this situation: there was an older version of “something” – the app, the program, the interface, the function. And now you need to create a new version (most often – because you are migrating to the new system), and you need to make sure this new version of “something” produces the same result.

First of all, this never happens. I’ve never experienced the situation, when the new procedure would produce “exactly the same result”. There are always mismatches.  And second, when you start to validate them in more details, turns out, that the “new” one is better, than the “old” one,  in a sense that most of the time it would turn out, that the new code fixed some issues of the old code :).

Moreover, quite often we already know, that the old code is wrong. But for some reason we are still trying “first to make in work, like then old one, and then fix it”.

Why?

I think in most cases it’s pure “phycological”. We think that the fact that the old code was running for a while and nobody complained, sort of validates it. But quite often the end users actually know about the errors, and they learned to correct then in the after-processing (at one of my consulting assignments I’ve learned that the error in the client financial software was know about for almost … 30 years!!!). Or people might not care. Or have no ways to validate correctness.

In any case, if we already know for sure that some parts are wrong, an we want to rewrite them anyway, I do not see a reason to “first replicate what it was”. It’s might be as easier (and better!) to gather new requirements, as if it was just another new development, and to  validate results against these requirements, not the old version!

Leave a comment

Filed under Development and testing