Jump to content







- - - - -

When your code does not work...

Posted by BlackRabbit, 15 November 2012 · 5,312 views

Success usually has many parents, failure remains an orphan until they figure out a way to put it on you.

That is one way to describe what the coder's life is about in result's perspective.

One of the worst things that can happen to you is your code being a failure, and in extension, causing damage to a bigger picture as in: delaying (or breaking down) the project and the business, pulling down the sales, or generating any money/time/or hardware loss.

It could happen in the worst of the moments, and in the least expected scenarios.

What is a coder to do when his program goes wrong and every finger is pointing on him?

There are many ways to deal with our coding problems, all of them concur in a simple concept: if you can't handle it, the faster you act on it the better.
What does that mean? the small problem of today might become the next week's unsolvable error, and next week will be the deployment...
Deadline-wise thinking, next week there will be less time to solve it than today, and while today many team mates could find amusing to help solve that problem, next week, with the client barking on the phone, the same people will just throw the errors in your face, with an ultimatum with it.

What is the worst thing that could happen if I don't pay that piece of dubious code the due attention?

Let me give you an example, a real life case, you don't need to go to Windows' blue screen on Bill Gates' presentation to get one ;)

There is a company that has a PBX remote programming service. Imagine a bank's building, like 20 stories, with two or three thousand people on it. got it?
All those people has a phone in their desk, and each phone (like 2.000) owns some intelligence that needs to be configured in order to fulfill its purpose, as in: which kind of calls is it allowed to do ( international, national, inter-branches, and the extensions directory of the building), also the smart office phones need its keys to be programmed, there is also the configuration on how the PBX connects with the telephony network, and how it decides how to course any call, and of course, the special outgoing routes.

You get the scope, Big bank - Big Sale.
The remote programers offer the bank a service's demo. They ask the bank for some phone-configuration's politics to apply to the whole building.
Sellers say the whole building's configuration will be done in less than two hours, while manually, in non complex configurations, a man does one phone each 15 minutes aprox. in complex cases the time grows. So... the whole building, up and running, consistent no-errors bot-made configuration in the time a single man does 8 phones, sounds like quite a service, doesn't it?

Well...
Its rush hour, video conference. Bank's board of directors attending in one side, the guy doing the selling speech in the other.

Sell-tale goes with the enthusiastic salesperson showing how easy was to configure everything with his software, Making the prelude to the : I press this button, and in less than two hours, your whole building will be reconfigured!
Man, did the guy feel like a lion in the jungle! like a king telling his army to attack!

They also say big high precedes big low. Well...
Button was pressed and seconds later... Video conference was abruptly cut... why?
the communication was of telephonic nature... and the client's building telephony service was suddenly not working anymore... no phone line in the whole building had tone anymore!! And you know... a bank's management building has as much telephones for a reason, they use them!!

Some demo huh! The error was in a routine that didn't met a condition and then... in absence of a clear course of action the programer opted to clean the records and exit... the routine was intensely iterated and gave no error notification to the iterator, so... total destruction said the insurance company!
The to-be-fired coder was instantly detected. Everybody went hands on to find the error, mostly to make sure they were not responsible. In this kind of situations, fixing the error is important, Saving your coding-butt is the priority.

The guy wasn't sure about some conditions in his routine, conditions that naturally wasn't present in testings. you know, a PBX network for over two thousand phones in the same building is not an easy to get testing scenario :P

Anyway, regular testings were OK, so the guy just let "the bomb" on there, thinking like: This condition is nuts, it will never happen, everything is gonna be all right.


CodeaBomber had many chances to cope with that code. He could have told his superiors, he could ask for specific testing, he could have asked for help to some teammate, he could have studied and researched more, but... he opted to: well, if something goes wrong I just wipe out the info, so no consequences... yeah!!... likewise!

So, you have always the option, Trying to help the solution or become codeAbomber.

So, remember.

Make sure to code properly for every condition. If you are not sure about certain code, exclude it from the program! better lack some functionality than having one that does not work.

Don't minimize the consequences, you don't know which city's electric network your program could be cutting off.

Anyway, its always nice to have your passport up to date, on a false identity if possible, your C.V stuffed and even some other possible profession. codeAbomber's life is on the road. Running away from his mistakes, escaping from lawsuits and being deleted from every linkedin contact he ever had.

Are you aware of how many bombs your code holds?


More BlackRabbit's entries:

. Understanding your fellow coders

  • 0



No comments? did everybody just rush to check out their in-production code ? :D
    • 0
Reminds me of when I made a "clever" SQL query to avoid having to code a loop. It allowed me to write one line of code instead of dozens. It worked beautifully. We deployed it to our largest customer, and the program locked up.

Turns out my "clever" query had a O(x^2) time complexity to it, and what ran great on a database with 100 records blew up fantastically on a database with 100,000,000 records. I recoded the logic to use a loop with O(x) complexity.
    • 0
Wings, i think i remember you talking about that, i think it wasn't that long ago!
    • 0
Yeah, that was a few years ago. It was a great lesson to me that a one line SQL query can have a significant computational complexity, and that I CANNOT ignore that fact.
    • 0
So what happened to that bad boy programmer and that bank and the client? Did they resolve the problem?
    • 0
Ha, truth is, I didn't post the whole story in order to keep it dramatic, but believe it or not, the sale went well, why?
Well, after that fiasco, the sellers put the automatic restore (from a backup done previous to the demo) to work, and in less than an hour the building was back and running, like before the crash, not with the new configuration.

That fast recovery from total down proved the point of the service being good and powerful. or course, better testing of functionality was required by the client, but the evidence of it working quick and for the whole satisfied them
well, with the big sale done, euphoria saved the guy's butt from getting fired, but now from the jokes coming from the rest of the team.
    • 1

April 2014

S M T W T F S
  12345
6789101112
131415 16 171819
20212223242526
27282930   

Recent Entries