Fixed it! or The strange case of the shared numbers.

Hello everybody!

Yes, it is hard to believe, even to me, but I have been working on the same problem for the third week in a row. Actually, if you see the incidents separately, they don't look like the same problem, but in fact they are. I could explain with all the technical terms and write a boring post which nobody will read.... or I can tell a simple and nice story, almost a fable, and write a interesting, maybe funny, post which nobody will read. Of course I'll do the second one.

Once upon a time a fresh and promising company. How any other company, this had some customers, there is no surprise on this fact. Those customer wanted to buy products, and this little company was exiting to sell them, so they were all, customers and company, happy. Sometimes, some of those customers, paid more than they wanted to buy, how can happen in any other company, where is no surprise on this fact. When this happened, the Company had no problem to give the money back to the customer, and this way, they
could be still being happy together.

On the paper the thing were as simple as that, but the company had to have all this transactions, -picking names randomly, orders when the customer bought, returns when the company gave money back- in the system, to keep the records, reports and other boring and administrative things which let the company grow up. Thereby about this time the company bought a system to manage all this data and implemented it on its guts. The system worked perfectly and everybody could be happy and probably was. This system, and now I'm about telling some highly relevant data -this is not a Sherlock Holmes story, I want you to keep the details, there will not be a living room scene-, assign a number to every order and return it generates. As curiosity, it can manage a number being shared to an order and a return with no complications, though it never had to do such a thing.

The company, with his new brand application was quite happy as a kid with a new brand toy. It could sell its products to its consumers and invoice then to keep the archive, and same with the returns. But the company, as every good one, was more ambitious than that. They wanted an application to rule them all. An application to automatize many of the processes that they have to do in the whole order's life cycle, with a friendly interface and a nice company logo on the main window. This application would be connected to the bought one, which was in charge of all this important staff about taking and giving money from and to the customers, but this new one could be in charge of all these particularities which made the company different to the rest.

This application was made by a person whom I never met, but whom I can tell a few things thanks to his code. How some wise one said one time: "Tell me how you code, and I tell who you are". This man was intelligent, and mainly autodidact, but he had no experience coding. Probably it was his first formal application and, frankly, this had to be an actual challenge to him. The thing is, when you know how to code, but are a strange to the right way to have the things done, is like if you know how to move chess pieces but have no idea about strategy. You can play, but probably you won't win. This developer played, and was beating problems as they was coming, and finally got a functional program which fit with the company expectations, but he didn't follow any strategy and the application, although it does whatever they wanted it to do, don't do anything in the correct way.

The database is a chaos, redundant data and mazy relations, crazy and unmanageable procedures and slowly-as-hell queries to generate views (usually a view is a optimized way to view the data... in this case is a madness guilty to have loading times to most of the windows in the application, loading times that people are used to manage as it was the most common thing and no-avoidable what's not true. And really wrong fields chosen to make the links between its database and the third party database which was being used for the company since beginning of the days. And this is the main protagonist of this history.

As I said, this third party application could work with shared numbers between orders and returns, although it never happened. This never happened because the two sequences of numbers was set with a big difference between them. What happen with these numbers on this new application? These numbers are used to link an order in the new system with the old one, but these numbers can be no-unique, thereby this link can link a single element of the new application with two, one order and one return with the other, the day in which the lower of the sequences reaches up the bottom of the higher one. In other words, this new application can't manage a shared number between an order and a credit note, and if someday these sequences match, this would be a doom. And nobody could foresee it.

All right, this date, the Doomsday  from now on (or D-Day -wink-), is not a theoretical date, it's not a scary tale to tell to those kids who doesn't like to eat their vegetables, this date is real, and it has its own name: 24th March 2015. This day everything went wrong with the invoicing system, and no one had a clue what was happened. Problems started to show up in many fronts, and when you could fix one, like a hydra, other two occupied its place. Luckily, and yes, it was just a big huge amount of luck, I found the problem and I set the number of one of the sequences about 800% bigger than the other, but the problem was still there. Before we realize this was the problem, many orders and returns shared the number, orders were duplicated and too many other boring things. Step by step I could fix every and each one of them (crossed fingers) related with this problem, but probably (pretty sure) my changes will have consequences in the future, because, you know, those Jenga pieces have been moved and the equilibrium of this maze has been altered.

At least I can tell I'm starting to map this labyrinth, and I think people in operations team are happy with me, what is the important. Ego's one is not going to be boosted by itself.

In next episodes...
Will a simple and foreign developer can beat the Minotaur of this labyrinth?
Will our charismatic protagonist buy a car so he doesn't have to take a taxi whenever lost a train?
Is he going to move out to a closer place soon?
Is he going to achieve a listening skill enough to watch anything without closed captions?
And the most important, will he can understand his workmates' technical problems at the first try?
Soon in your computers. Don't lost!