In after-hours trade on Monday, NYSE deployed test code to production It looks like the New York Stock Exchange took the opportunity of an abridged trading session ahead of the fourth of July to test some code relating to its API. The problem is, test seems to have gone to production with the hilarious result that a bunch of stocks are reporting the same value: $123.47 (which, as someone noted …
There are bizarre rounding rules. Like normal people round 1.5 to 2, and 1.4 to 1.
Beancounters often consider the next digit if the digit is 5. So...
1.50 becomes 1
1.51 becomes 2
1.52 becomes 1
1.53 becomes 2
1.54 becomes 1
and so on.
...
Though that still doesn't explain the 7. Maybe someone tried to write financial code in Java and wanted to test their rounding code, did this with the number 123.456, left in the test code... and failed.
Double rounding can lead to such funny results. That's why I warn quants against applying directional rounding unnecessarily. For example: round 123.456 to second decimal place to 123.46 (which cannot be represented accurately in IEEE-754 meaning there is some FP representation error in there already), then process this number in some way apparently not changing it (but possibly affecting existing FP error), and then round up to second decimal place again. The result? An extra FP error will push up the result of second rounding to 123.47, from 123.46+epsilon
Had an MRI last week; the bill was $1234.56. So I thinks, "damn, someone left a default value in - gotta make a phone call. This is Not Kwite Rite."
Call outcome? Basically it doesnt matter what they charge and the number is in fact rectally derived. At the end of the day the scan costs precisely as much as whatever insurance company will pay them for said exam. No insurance? Guess you win the random variable prize?
Welcome to healthcare, USA style.
I do systems integration work for an IT services company (a competent one, not Capita or similar.) Basically, the party line industry-wide is if you're not fully on board with DevOps, you won't have a job for very long. Anyone who even suggests that developers shouldn't have full access to production systems and the ability to check random code in at any time is an old fossil sysadmin who's just trying to protect his job.
What companies aren't getting is that DevOps really isn't just "fire your sysadmins and make the devs run their own boxes" for anything more critical than some random phone app. The concepts are really good, and this is coming from someone in an environment where the pace of change is glacial at best. What gets lost in translation is that the thing you're trying to fix is the nightmarish pain that a change can bring once the devs throw the code over to the ops. I've had operations teams say to me with a straight face that they can't deploy code until their entire staff is certified on the latest version of Windows Server. I've had operations teams refuse to accept things without a runbook explaining every possible thing that could go wrong with the system. And use that same runbook as an excuse to send every single thing that wasn't in the runbook up the chain to product engineering even though it's Sysadmin 101 stuff.
It makes sense for both sides to learn about the other. There are some developers I wouldn't let 100 feet from a production system simply because they've shown they have no idea how a computer works beyond the tools their language of choice provides. Some operations people are so hidebound in process that they're just too slow to keep up with changes. Like all things bubble-related, once this dotcom bubble bursts and the SV startups recede into the background again, I think we'll take the parts of DevOps that make sense and use them everywhere.
So what I think you are saying is that buzzword bingo does not teach common sense? I can see the value of teaming developers and operations personnel so that they can learn to communicate and jointly address deficiencies. Heck, sometimes is good to have a person detail to another stovepipe just to break up boredom and give them additional growth oopportunities. Sometimes a shuft from one part of the org to the other - done voluntarily and with the employee's best interests foremost - can jump start a career and build useful bridges between organizations. If a guy or gal leaves my org I want them to leave happy and predisposed to team with ua, no matter where they go.
But all that requires real investment from leadership to see people as unique individuals with specific gifts to offer rather than a homogeneous mass of "human resources". Leading teams of individuals is really hard work! I think part of the DevOps fascination is that its easier to just hire a septic think tank to come in and (not) do this job for you.
DevOps feels like the forced fun mandatory holiday parties, or maybe regret/pity sex. If youve not been doing your job all along a sudden forced fun session isnt going to be very satisfying.
-BC
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
