Where the platform is managed and enforces the metric, that’s where this shit happens the most.
SOP for the big salesforce consulting shops, especially WITCH folks.
Funny thing is, this is why Salesforce has a maximum number of lines of code.
You can raise the ceiling if you ask, but they will only do it after an inspection looking for shit like this.
People don't choose Salesforce, companies do :).
Companies don't care about the same things developers care about. Uptime, PaaS and out of the box features sell.
Everyone is saying this is Salesforce and is a required part of their prod deployment or something but I'm confused how it calculates coverage.
The tool my team uses seems more to just analyze the possible stacks and then which ones are hit with a test case. You can get way with not writing asserts or verifying anything, but usually once you have the code path hit it's not hard to make an at least somewhat robust test.
I'm just curious how this actually translates into test coverage. It is just "number of lines in files under /test must be 75% of number of lines in files under /src"? Because that's ridiculous
% of executable lines of code, rather than % of paths taken. So an untested path (like error handling) doesn't count against you that much if it's not many lines of code, and writing i++ thousands of times counts for you *a lot*
Even funnier they continually added more lines as needed per commit.
Edit:
Yup, Salesforce repo. I’m not a salesforce dev but the repo came under our team’s umbrella. We had a pretty good laugh. I actually didn’t know it was enforced on the Salesforce side until this thread!
There's nothing wrong with a mandate, code coverage is extremely important and it's simple to write test classes. However, if you don't have any oversight of that mandate, you end up with this mess.
There's a lot wrong with mandate. Mandate encourages devs to write useless tests just to cover lines. Tests **can be detrimental to your codebase**. Good tests check code's behaviour, bad tests check exact implementation. In second case any change will fail test, which means they no longer protect from regression as devs no longer even question tests breaking. They just see it as natural that literally any change in code requires adjusting tests to pass again.
I'll take a **warning** about low coverage combined with review by someone that will point out that something worth testing wasn't tested, over mandate any day
In unit tests with dependencies, the line between implementation and behavior can be very fine.
The vast majority of interfaces are very weak contracts, and sometimes a test that's philosophically too close to the metal is still useful as a pinning test or for the implementor to vet that they wrote the lines of code they thought they did.
It's very rare that touching code doesn't alter the behavior (why else did you touch it?) regardless. Any test break should be analyzed for if it's expected, but breaks should be expected with changes that are not purely additive.
My rule of thumb is that the integration tests are more robust, behavior-focused and intended for future authors. The unit tests are more rigid and intended primarily for initial authoring.
way to easy to spot, insted transfer yourself the floating point Rounding Error that come exist because flaoting point is a bit fucked, for example:
you would think that
3.0 \* 0.2 = 0.6
but in reality, because floating point arithmetic makes no sense:
3.0 \* 0.2 = 0.60000000000000001
so just transfer yourself the 1 at the end , with how many bank transfers there are every second you will have millions in no time
I've got one and it's actually a quality stapler. Has some real heft to it. You just know you could beat some middle manager to death with it and go on stapling afterwards. The red also hides the bloodstains quite well. A++++ Highly recommend.
if a bank is using floating point numbers then it should not exist XD
Although whatever representation modern banks do use, there will still be some imprecision, just not as much as floats
The minimum resolution of a stock price is $0.0001 and the minimum number of shares is 0.01, so microdollars seem to be the smallest unit.
Oh, and as to the point... The vast majority of accounting is done to cents, or *at most* mils, so there's plenty of salami slicing to do with the last three decimal points.
The rounding happens anyway, but you always round one side of the solution up and the other down depending on some set up rules.
I had a hand in some of the accounting done, and trust me there is no way to siphon of money in today's banks, because you still have to hack not just the point where you take away the money but also the balance checks that happen from in and outgoing transactions. If they don't hold up for a single penny the whole bank is looking for it and they will find it.
Adding to that, accounts that increase in value without incoming payments will be flagged by secondary software anyway.
The only way to get money from a bank from the inside is to continue working there ;p
Not in pennies but in sub-pennies. US equities require 1/100th of a cent, and I think FX requires 6 or 8 decimal precision depending on where.
Source: I build order management systems for a living.
IIRC, it's based on a true story. The practice is called "Salami Slicing", and there's a few known incidents of people trying it, to varying success. Modern financial systems have safeguards, but it was definitely a real thing in the past
When you think about with what precision you want to store 'standard' variables without making their computation quite slow: the binary representations of those numbers simply take a lot of time to be run through the processors registers due to architecture (64 bit, usually) so look closer at that binary format - it gets clear that at some point you have to balance speed and precision against each other - in a general purpose CPU. That'll be making sense to y'all, too, just dig into digital number crunching:
[Food for thought](https://en.wikipedia.org/wiki/Double-precision_floating-point_format)
Not as funny as this but I had a coworker once that was talking about his code repo having 97% coverage. When he left another coworker and I looked at it and he literally had unit tests with no assert statements or any other checks.
I have seen so many bullshit Salesforce consultants do this, and every time I want to gouge their fucking eyes out, because that meant I had to go back and clean up their mess in addition to whatever work I had to do.
I don't have 100% code coverage in my own package, but my coverage isn't padded like this.
Goodhart’s law was originally stated as a rule of economic policy, but it is much more widely applicable.
“Reward hacking” in optimization problems is a great example of this (“optimization” here goes well beyond just the ML examples someone may normally refer to). Organizational issues at a company oftentimes come from a failure to account for this, resulting in employees aiming to do whatever gets them recognition come review time (even if this doesn’t actually align with company interests).
>resulting in employees aiming to do whatever gets them recognition come review time (even if this doesn’t actually align with company interests).
Great example is "your goals can't be the work you do every day".
O, OK, you want me to sacrifice my actual job in order to do whatever bullshit you made me make up for my goals? Can do.
They did this to me this year. They wanted us to show that we were improving ourselves and that we were meeting our goals of career development, but getting involved with other teams, new projects, etc. didn't count. Had to be something beyond your job. So instead of the year I spent where I was constantly improving myself by being part of a project that no one in the company had done before, I "checked the box" on improvement by watching a 4 hour video about some bullshit because that's what HR wanted.
Omg I thought my company was the only one that did this...
Also to get a chance at promotion you have to complete 8 hours of completely pointless "softskill courses" lol ...so people in busy projects have no time for that but those that don't have any work to do have plenty of time to get promoted sooner lmao
They love to promote box checking idiots, not actually useful people. They need to keep the useful people doing their jobs so the idiots can make money from them.
> Is the solution to Goodhart's law as straightforward as "measure what you benefit from"?
Call centers have this problem. They (sometimes) get paid by the phone call. So they set up metrics to track and reward the employees based on number of phone calls taken. That works great, until other things suffer (customer satisfaction, early disconnects, unnecessary transfers, etc).
It's a real challenge (and a big part of why working in a call center sucks to bad.)
Sounds like so many businesses out there nowadays. The ones that make employees beg for 10s in the review or in specific categories or to sell some credit card.
Not really, it comes down to fundamental human behaviour. You cant really "solve" bad will or corruption. My only advice is to put more emphasis on having good people working at the company rather than any one specific measument, but that goes squarely against "SMART" goals so... YMMV
I don't think there's a straightforward solution that doesn't just lead to another Goodhart's Law example. You need a flexible organization able to evaluate an employee/product/solution/whatever with measures other than a few key numbers.
My personal opinion, from seeing a lot of really bad data driven management, is that you want to track stats, but you only want to flag outliers. Flag, not take automatic action on. So the worst and best 5% of anyone, by the numbers, there is *something weird* going on, and it is probably bad or neutral but maybe good, and almost always worth having someone figure out what the fuck is going on.
Specific example: My company fires the worst X percent of employees per department each year. This is dumb. They fire people who are just fine. People know it’s coming so they juice their metrics and kiss up to their managers. Managers hire people just so they have a sacrificial lamb if they like all their people. It instills a really bad environment.
I have also worked somewhere that also never fired anyone, basically ever. That was also a problem. People sometimes did really obviously no work at all, or didn’t know how.
Happy medium: If a part of a large company has an *outlier* number of departures — high or low — follow up and figure out why. Probably it means management sucks — but if you make it a for sure thing that management gets in trouble for it, you will end up with managers who just work to hit the number and don’t care how well things are going.
I think you hit the nail on the head for me here, thank you. Other people here are trying to make a case that this is somehow a principle that says you can't tie employee activity to business benefit, and I don't think that's true. You can at least do it in the abstract - "more meetings probably mean more dollars" - but to your point, it's that you can't create a metric that is un-gameable. Any number you pick, someone somewhere will figure out how to get to that number in a low-quality way.
Thats my greatest gripe on todays recruitment processes. It became an arms race of buzzwords and gimmicks that have less and less to do with the skills and work you are applying
The NHS in the UK wanted to ensure outpatients would be quickly seen by doctors so they introduced a target that all patients had to be seen by a doctor within a certain amount of time.
The doctors, overworked and understaffed applied the rule literally, basically going up to patients as they arrived, saying hello, then telling them to wait.
Similarly silly story from Denmark:
When I was diagnosed with ADHD the psychiatrist who did it told me he'd refer me to the psychiatric hospital and they would figure out what kind of medication I should be put on and do followups etc.
I made an offhanded comment saying something like "so I'll get an appointment 6 months from now?" and was told "no no, they're required by law to start no later than 90 from when they receive my referral"
A couple days later I receive a letter stating "We've received your referral on *date* and you have an appointment *89 days later*"
I go to said appointment and I kid you not, ignoring commute and sitting in the waiting room it lasted 3 minutes, basically just them telling me what they could offer me and I was sent on my way. My 2nd appointment was nearly **6 months** after the first one, so in total almost 9 months after my referral I had my first "real" appointment, but I had my first one within the required 90 days, so it's all by the books.
For sure. My work performance and bonus is tied to all sorts of BS measures like commits per day and and auto generated “impact” scores that have no real bearing if you ask me. Now I’m more worried about pushing out a few phony commits at the end of the day than I am about solving the code problem
How in heck does commits per day relate to any sane metric that can rate performance?
I can write a small program that simply issues commits at random in its own cursor so that it impacts nothing else. Is someone running reports against the log files to determine how useful the commit is?
> How in heck does commits per day relate to any sane metric that can rate performance?
1. Brass demands numbers for measuring development
2. Someone gives them things like that just to shut them up
3. Brass, now that they have numbers, decide to use that as targets
4. *Insert full clown face*
Should have named it ImportantTimerCountFunction and pretend all the increments are some esoteric way to avoid a race condition.
Edit: even better, instead of incrementing by one add some numbers but do it in hexadecimal so it looks extra spooky.
mem_var += 0x00054ff8;
mem_var += 0x000b8ee1;
do you really wanna be the one to remove a hexadecimal magic number from some code you don't know?
``//I have no fucking idea why, but nothing works when I remove this function, I can’t find a single reference anywhere else and sometimes adding lines to this fixes strange issues``
Blame averted
Haha first things I did once I saw this.
The repo belonged to a different team, and the contributor left long ago. Looks like they were the only one active in it for a while, which makes me question why they didn’t simply remove the check lol.
We do pretty strict reviews here, so this must’ve been way before the reviewers requirement was placed - for this repo at least.
Edit:
After reading the comments, turns out SFDC enforces this code coverage to push to prod. Didn’t know that!
The check is automatically enforced by Salesforce PROD instances, so this is a bypass to get code in to PROD without having to write/update a test class
Tbh I’ve done it before to force a hotfix on a weekend, but would always fix it Monday as it’s pretty shameful shit 🙈
> this must’ve been WHY the reviewers requirement was placed
If it was, the repo would have already been removed.
Since it wasn't, clearly nobody knew about this.
An old coworker of mine did something similar. He got stuck on an app that a bunch of people had basically shat out over several years, and like a week after he got stuck on it, the team decided they needed 90% coverage for all their apps. He was like this is fucking impossible, to which the manager promptly responded your problem not mine. So he wrote a bunch of unit tests that called all the functions, caught every exception, and did no validation, just did `assertTrue(true)` at the end. He wasn't proud of it, but his job was on the line, so I don't blame him.
We had an API like that. Huge pressure from management to make it performant under load, so dev built a load tool to send thousands of requests and measure response times. They got a nice reward for demonstrating that the current infrastructure was good for contracted service times at nearly twice the projected load.
I got no reward when I demonstrated that their tool didn't verify the response properly, so at 30% or higher loads, the API responded quickly with a "no service" message, that they were incorrectly classifying as SUCCESS. It basically stopped working, but at least it gave an error message within the projected response time.
Be careful what you measure. That's exactly what people will work to give you.
One of our API's here at work got a requirement to have max half a second response time. Apart from a very few exceptions, I knew that it delivered way inside that, usually within 50ms.
Then I got a report from CTO saying that most took 1-2 seconds to respond, including what's basically an echo service *(it reads the token and responds with the token's content in a readable format)* that's normally 10ms reported as 1.4 seconds.
After a lot of back and forth I found out how the report was made. Big java framework, ran on an old machine, from *India* over who knows what lines...
Got them to run the test from a local, beefy machine instead and suddenly the numbers were muuch better. Must be magic.
Yes, this is similar to what I've seen with people running sql locally, and complaining that it was taking a long time, but it turns out they were selecting a large amount of data over a VPN. Server handles the query just fine, but the raw transfer made it seem like the query was taking up to a minute.
Huh? Hitting all the branches is like 3/4 or more of the effort, then you just have to assert whatever came out the end when running it. Seems to me like asserting true at the end is just sticking it to them for making an arbitrary code coverage requirement?
I wasn't there for it, but he didn't exactly hit the branches gracefully based on what he told me. It was literally cobbling things together until a branch got hit. If the data was wildly off, he didn't care. The `assertTrue` was because the code scan tools would flag the tests if they didn't have any assertions, although sticking it to them certainly wasn't outside of his wheelhouse either.
The problem usually comes in when this requirement is added to a pre-existing code base that has never had a coverage requirement before. You could stop feature work for a few weeks to catch up and make the numbers right but management isn’t gonna allow that, you need to keep shipping code…so you pad the coverage to 75% to get a deploy out he door and tell yourself you’ll come back and right the real tests later. But now you don’t have any time budgeted to do that because “well we’re already at 75%”. I haven’t done this exact tbh if before but I’ve done shit that was this stupid to meet an arbitrary target on an unrealistic deadline that Cannot Be Moved
Go ahead and change the file extensions and ratio as needed:
% for i in $( seq $(echo $(echo $(for f in $(find . \( -name \*.c -o -name \*.h \)); do wc -l $f | cut -d' ' -f1 | tr '\n' + ; done)0 | bc)'*75/100' | bc ) ); do echo i++\;; done > /tmp/filler.c
I’m guessing Salesforce?
We had a merger with a company that had such a huge single class that adding enough I++ to it to pass the coverage for a fix to a company stopping bug exceeded the file size.
But you you make the whole class 1 line
That's also why having a bullshit metric just to have one is a problem. Clearly someone just wanted to see the build box report 75+% coverage, and the devs satisfied the requirement.
Yeah I never liked code coverage, especially applied to legacy code bases where it can be nigh impossible to get certain parts unit testable.
“When a metric becomes a target, it’s no longer a good metric” or something to that effect.
I feel like the root problem is that lines of code is a technical metric. Too many non-technical people think that more lines of code automatically means more stuff is getting done. A programmer can add 10 lines of really important code and have added far more value than a guy mashing 1000 lines a day.
100% Code coverage is not an indication of well tested code, but 10% code coverage is an indication of poorly tested code. Use the metric for what it's purpose is.
I had a colleague who should be paid by character because I found several things like this:
```
If var = "something" or var = " something" or var = " something " or var = "something " Then
' code for something
End If
```
( Yeah... , in VBScript, because the language alone is not bad enough )
he also didn't use arrays, functions or objects, some files have more than 9000 lines
Code coverage is how much of the code is executed (covered) during testing. Pretend you have 10 functions, each with 5 lines of code, and somehow no other code in the project.
If your tests call 1 of the functions, you have 10% coverage.
If your tests call 2 of the functions, you have 20% coverage.
And so on...
Now let's say you have three functions, one called `fakeCoverage()` with 10 lines, one called `realWork()` with 10 lines, and one called `notCovered()` with 10 lines. The first two are called during testing but the last one is not. Your code coverage is therefore 2/3 or about 66.67%.
Say you add 10 more lines of code to `notCovered()`. Your code coverage has now gone down to 50%. But if you add 20 more lines to `fakeCoverage()`, suddenly it's back up to 66.67%.
To my understanding code coverage is code that is tested/has unit tests. So they add 3 lines of code to a spot that's untested and 20 lines to this fake function and fix the test to pass for the new lines. So that way 75% or more had test coverage.
I have seen no evidence whether or not Elon can write a loop. I have seen evidence showing that Elon CANNOT write an if statement.
https://twitter.com/elonmusk/status/1629633384338149378/photo/1
I never understood this, assuming code reviews, what are the chances of two people willing to cooperate on something like this, and not already been fired?
…. Then this past week happened. I came back to a project to find CI broken. Among many other shenanigans, one dev got a manager to disable the CI check so he could merge anyway, and this manager rubberstamped the code review, no technical review at all. WTF
This likely isn’t the result of a malicious bunch of programmers. More likely some C-level dork decided that all repos need to have 90% code coverage, and that was impossible for a legacy repo. Easier to do something like this to make the C-level happy than to try to fight your way up through the chain of command to explain why the policy is dumb.
ELI5 version is code coverage = (number of lines your test cases hit)/(total number of lines).
This company says code coverage must be 75% or better (3 of every 4 lines are tested). Someone had less than that. Instead of writing more tests (what you're supposed to do), he added one test and a bunch of nonsense lines, not improving anything.
I'm 99% sure this was me! I had to deprecate your code base from a prod environment for a client and Salesforce kept giving me shit about meeting 75% code coverage, even after I commented out/deleted the entire class. Made no sense to me how to cover something that didn't exist.
Your rep didn't respond to a single email trying to give him a heads up and ensure everything would be good so I had to wade off into this shit by myself with no clue what impacts there would be. Obviously it's tied to your repo, which I wasn't aware of.
It was midnight, I had deprecated most of the package, and I was down to like 8 or 10 pieces of Apex code that simply wouldn't uninstall because of the dependencies. Thus, this horrific act of code was born. *And it didn't even fucking work.* I ended up doing the smart thing at the end, which was deleting every piece of code through the CLI all at once.
> The guy was fired and sued
Fired i understand. But the fuck did they think suing him would do?
Clearly this code (kind of thing anyway) doesn't introduce any vulnerabilities. All it does is take up some hdd space, at best. And if it's being excluded from release compilations (which is super likely), it isn't even being *used* in the product.
If the guy was given a metric for commits, he was *meeting the requirement*. Not his fault if the company was implementing a *stupid* metric.
Depending on what the suit was specifically claiming, easy win on his part.
Salesforce: Wait. That's illegal
Where the platform is managed and enforces the metric, that’s where this shit happens the most. SOP for the big salesforce consulting shops, especially WITCH folks.
What does the word WITCH mean here?
Each letter stands for an Indian consulting company, I’m not sure what they are off the top of my head though
Wipro, Infosys, TCS, Cognizant, HCL
Hmmm.... So, Adani Group acquired Cognizant as well...
Almost all metrics lead to shit like this, which is why almost all metrics are worthless. If it’s game-able, it will be gamed.
Goodhart's law. *"When a measure becomes a target, it ceases to be a good measure"* https://en.m.wikipedia.org/wiki/Goodhart%27s_law
[удалено]
Let's find a group of people that solve problems all day a set of random metrics we are going to judge them on, Gee, whatever could go wrong.
Funny thing is, this is why Salesforce has a maximum number of lines of code. You can raise the ceiling if you ask, but they will only do it after an inspection looking for shit like this.
I don't get why people use salesforce if they dictate what you can and can't do with your own code.
People don't choose Salesforce, companies do :). Companies don't care about the same things developers care about. Uptime, PaaS and out of the box features sell.
Exactly what I was thinking, Salesforce pre-2017 or so.
[удалено]
Everyone is saying this is Salesforce and is a required part of their prod deployment or something but I'm confused how it calculates coverage. The tool my team uses seems more to just analyze the possible stacks and then which ones are hit with a test case. You can get way with not writing asserts or verifying anything, but usually once you have the code path hit it's not hard to make an at least somewhat robust test. I'm just curious how this actually translates into test coverage. It is just "number of lines in files under /test must be 75% of number of lines in files under /src"? Because that's ridiculous
% of executable lines of code, rather than % of paths taken. So an untested path (like error handling) doesn't count against you that much if it's not many lines of code, and writing i++ thousands of times counts for you *a lot*
Even funnier they continually added more lines as needed per commit. Edit: Yup, Salesforce repo. I’m not a salesforce dev but the repo came under our team’s umbrella. We had a pretty good laugh. I actually didn’t know it was enforced on the Salesforce side until this thread!
Well; clearly no review happens there. Slip in a hack to add a penny to your account for every transaction..
That's Salesforce Apex. You need 75% code coverage to deploy anything to a prod instance. This shit is common AF in smaller orgs.
[удалено]
> requires anything going out the door to have 85%+ coverage ooooooh nooooooo
Just alternate the i++'s and i--'s, lol
`--(i++)` 💪😤
>\--(i++) What language is this?
It’s definitely a programming language
[удалено]
There's nothing wrong with a mandate, code coverage is extremely important and it's simple to write test classes. However, if you don't have any oversight of that mandate, you end up with this mess.
There's a lot wrong with mandate. Mandate encourages devs to write useless tests just to cover lines. Tests **can be detrimental to your codebase**. Good tests check code's behaviour, bad tests check exact implementation. In second case any change will fail test, which means they no longer protect from regression as devs no longer even question tests breaking. They just see it as natural that literally any change in code requires adjusting tests to pass again. I'll take a **warning** about low coverage combined with review by someone that will point out that something worth testing wasn't tested, over mandate any day
In unit tests with dependencies, the line between implementation and behavior can be very fine. The vast majority of interfaces are very weak contracts, and sometimes a test that's philosophically too close to the metal is still useful as a pinning test or for the implementor to vet that they wrote the lines of code they thought they did. It's very rare that touching code doesn't alter the behavior (why else did you touch it?) regardless. Any test break should be analyzed for if it's expected, but breaks should be expected with changes that are not purely additive. My rule of thumb is that the integration tests are more robust, behavior-focused and intended for future authors. The unit tests are more rigid and intended primarily for initial authoring.
way to easy to spot, insted transfer yourself the floating point Rounding Error that come exist because flaoting point is a bit fucked, for example: you would think that 3.0 \* 0.2 = 0.6 but in reality, because floating point arithmetic makes no sense: 3.0 \* 0.2 = 0.60000000000000001 so just transfer yourself the 1 at the end , with how many bank transfers there are every second you will have millions in no time
You forgot the part about misplacing the decimal and in fear of getting caught, burn the building down. Has anyone seen my stapler?
I always forget some mundane detail
Mundane?!
It's a red swing line, it's anything but mundane
Fun fact: Swingline didn't make a red stapler at the time Office Space came out. They made one later and it became their best selling stapler.
I own it and love it. I get why it was such a big deal in the movie.
I've got one and it's actually a quality stapler. Has some real heft to it. You just know you could beat some middle manager to death with it and go on stapling afterwards. The red also hides the bloodstains quite well. A++++ Highly recommend.
This is *not* a mundane detail, Michael!
I always thought he said “Monday” detail. Eye opening revelation.
Sounds like somebody's got a case of the Mondays
Pretty sure you'd get your ass kicked saying that around here.
Check out channel nine!
Milton did not misplace a decimal or have fear of getting caught.
Damn it feels good to be a gangster
if a bank is using floating point numbers then it should not exist XD Although whatever representation modern banks do use, there will still be some imprecision, just not as much as floats
What imprecision would arise from storing integer(bignum) amount of pennies?
The minimum resolution of a stock price is $0.0001 and the minimum number of shares is 0.01, so microdollars seem to be the smallest unit. Oh, and as to the point... The vast majority of accounting is done to cents, or *at most* mils, so there's plenty of salami slicing to do with the last three decimal points.
The rounding happens anyway, but you always round one side of the solution up and the other down depending on some set up rules. I had a hand in some of the accounting done, and trust me there is no way to siphon of money in today's banks, because you still have to hack not just the point where you take away the money but also the balance checks that happen from in and outgoing transactions. If they don't hold up for a single penny the whole bank is looking for it and they will find it. Adding to that, accounts that increase in value without incoming payments will be flagged by secondary software anyway. The only way to get money from a bank from the inside is to continue working there ;p
Multiple everything by a bazillion and then divide it when paying out
>A bank error resulted in our transferring everything to our CEO, please bail us out as he disappeared afterwards and won't pick up his phone
[удалено]
If you're not using fixed point numbers for currency you get what you deserve.
And this is why you use integer types for money, counting in pennies.
Not in pennies but in sub-pennies. US equities require 1/100th of a cent, and I think FX requires 6 or 8 decimal precision depending on where. Source: I build order management systems for a living.
Zimbabwe my good man, that shit crushed most forex calculations, Hyperinflation is a motherfucker.
Isn't this literally the exact plot of Office Space?
IIRC, it's based on a true story. The practice is called "Salami Slicing", and there's a few known incidents of people trying it, to varying success. Modern financial systems have safeguards, but it was definitely a real thing in the past
[удалено]
[удалено]
Who, if not you?
Try Superman III...
Has someone tried taking few frames from different movies and making a movie of their own?
Kung Pow: Enter the fist or any YTP really
DAT'S DA JOKE
When you think about with what precision you want to store 'standard' variables without making their computation quite slow: the binary representations of those numbers simply take a lot of time to be run through the processors registers due to architecture (64 bit, usually) so look closer at that binary format - it gets clear that at some point you have to balance speed and precision against each other - in a general purpose CPU. That'll be making sense to y'all, too, just dig into digital number crunching: [Food for thought](https://en.wikipedia.org/wiki/Double-precision_floating-point_format)
Useless He should have scripted it with a git precommit hook instead of manually adding more lines. Newbie
Well as with many other things after a point you're just in too deep and any hope of solving the problem seems like a unrealistic dream...
Not as funny as this but I had a coworker once that was talking about his code repo having 97% coverage. When he left another coworker and I looked at it and he literally had unit tests with no assert statements or any other checks.
I have seen so many bullshit Salesforce consultants do this, and every time I want to gouge their fucking eyes out, because that meant I had to go back and clean up their mess in addition to whatever work I had to do. I don't have 100% code coverage in my own package, but my coverage isn't padded like this.
I’ve never seen Goodhart’s law be so straightforwardly demonstrated. “When a measure becomes a target, it ceases to be a good measure.”
I’ve never heard that, but that’s so true.
Goodhart’s law was originally stated as a rule of economic policy, but it is much more widely applicable. “Reward hacking” in optimization problems is a great example of this (“optimization” here goes well beyond just the ML examples someone may normally refer to). Organizational issues at a company oftentimes come from a failure to account for this, resulting in employees aiming to do whatever gets them recognition come review time (even if this doesn’t actually align with company interests).
>resulting in employees aiming to do whatever gets them recognition come review time (even if this doesn’t actually align with company interests). Great example is "your goals can't be the work you do every day". O, OK, you want me to sacrifice my actual job in order to do whatever bullshit you made me make up for my goals? Can do.
They did this to me this year. They wanted us to show that we were improving ourselves and that we were meeting our goals of career development, but getting involved with other teams, new projects, etc. didn't count. Had to be something beyond your job. So instead of the year I spent where I was constantly improving myself by being part of a project that no one in the company had done before, I "checked the box" on improvement by watching a 4 hour video about some bullshit because that's what HR wanted.
Omg I thought my company was the only one that did this... Also to get a chance at promotion you have to complete 8 hours of completely pointless "softskill courses" lol ...so people in busy projects have no time for that but those that don't have any work to do have plenty of time to get promoted sooner lmao
They love to promote box checking idiots, not actually useful people. They need to keep the useful people doing their jobs so the idiots can make money from them.
[удалено]
Is the solution to Goodhart's law as straightforward as "measure what you benefit from"?
Except that you can't always do that directly. You can't link profits directly to the actions of a specific employee.
That's usually not very straightforward to measure.
> Is the solution to Goodhart's law as straightforward as "measure what you benefit from"? Call centers have this problem. They (sometimes) get paid by the phone call. So they set up metrics to track and reward the employees based on number of phone calls taken. That works great, until other things suffer (customer satisfaction, early disconnects, unnecessary transfers, etc). It's a real challenge (and a big part of why working in a call center sucks to bad.)
Sounds like so many businesses out there nowadays. The ones that make employees beg for 10s in the review or in specific categories or to sell some credit card.
Not really, it comes down to fundamental human behaviour. You cant really "solve" bad will or corruption. My only advice is to put more emphasis on having good people working at the company rather than any one specific measument, but that goes squarely against "SMART" goals so... YMMV
I don't think there's a straightforward solution that doesn't just lead to another Goodhart's Law example. You need a flexible organization able to evaluate an employee/product/solution/whatever with measures other than a few key numbers.
My personal opinion, from seeing a lot of really bad data driven management, is that you want to track stats, but you only want to flag outliers. Flag, not take automatic action on. So the worst and best 5% of anyone, by the numbers, there is *something weird* going on, and it is probably bad or neutral but maybe good, and almost always worth having someone figure out what the fuck is going on. Specific example: My company fires the worst X percent of employees per department each year. This is dumb. They fire people who are just fine. People know it’s coming so they juice their metrics and kiss up to their managers. Managers hire people just so they have a sacrificial lamb if they like all their people. It instills a really bad environment. I have also worked somewhere that also never fired anyone, basically ever. That was also a problem. People sometimes did really obviously no work at all, or didn’t know how. Happy medium: If a part of a large company has an *outlier* number of departures — high or low — follow up and figure out why. Probably it means management sucks — but if you make it a for sure thing that management gets in trouble for it, you will end up with managers who just work to hit the number and don’t care how well things are going.
I think you hit the nail on the head for me here, thank you. Other people here are trying to make a case that this is somehow a principle that says you can't tie employee activity to business benefit, and I don't think that's true. You can at least do it in the abstract - "more meetings probably mean more dollars" - but to your point, it's that you can't create a metric that is un-gameable. Any number you pick, someone somewhere will figure out how to get to that number in a low-quality way.
Also known as the perverse incentive. Where the incentive selected drives the opposite behaviour to what it aims to solve
Thats my greatest gripe on todays recruitment processes. It became an arms race of buzzwords and gimmicks that have less and less to do with the skills and work you are applying
The NHS in the UK wanted to ensure outpatients would be quickly seen by doctors so they introduced a target that all patients had to be seen by a doctor within a certain amount of time. The doctors, overworked and understaffed applied the rule literally, basically going up to patients as they arrived, saying hello, then telling them to wait.
Similarly silly story from Denmark: When I was diagnosed with ADHD the psychiatrist who did it told me he'd refer me to the psychiatric hospital and they would figure out what kind of medication I should be put on and do followups etc. I made an offhanded comment saying something like "so I'll get an appointment 6 months from now?" and was told "no no, they're required by law to start no later than 90 from when they receive my referral" A couple days later I receive a letter stating "We've received your referral on *date* and you have an appointment *89 days later*" I go to said appointment and I kid you not, ignoring commute and sitting in the waiting room it lasted 3 minutes, basically just them telling me what they could offer me and I was sent on my way. My 2nd appointment was nearly **6 months** after the first one, so in total almost 9 months after my referral I had my first "real" appointment, but I had my first one within the required 90 days, so it's all by the books.
For sure. My work performance and bonus is tied to all sorts of BS measures like commits per day and and auto generated “impact” scores that have no real bearing if you ask me. Now I’m more worried about pushing out a few phony commits at the end of the day than I am about solving the code problem
How in heck does commits per day relate to any sane metric that can rate performance? I can write a small program that simply issues commits at random in its own cursor so that it impacts nothing else. Is someone running reports against the log files to determine how useful the commit is?
> How in heck does commits per day relate to any sane metric that can rate performance? 1. Brass demands numbers for measuring development 2. Someone gives them things like that just to shut them up 3. Brass, now that they have numbers, decide to use that as targets 4. *Insert full clown face*
I prefer the more colloquial term "lost in the sauce"
I prefer “juking the stats”
Cobra effect
`public static void fakeCoverage(){ ... }` Well, at least they were honest.
It's self-documenting
And self-incriminating
Should have named it ImportantTimerCountFunction and pretend all the increments are some esoteric way to avoid a race condition. Edit: even better, instead of incrementing by one add some numbers but do it in hexadecimal so it looks extra spooky. mem_var += 0x00054ff8; mem_var += 0x000b8ee1; do you really wanna be the one to remove a hexadecimal magic number from some code you don't know?
``//I have no fucking idea why, but nothing works when I remove this function, I can’t find a single reference anywhere else and sometimes adding lines to this fixes strange issues`` Blame averted
And self-incrementing!
OP doing the once a millenia review for this repo
OP needed meme arrows, so decided to review code and post something.
Or, and hear me out, OP typed this into a text editor and took a screenshot
Lol no this shit is super common for Salesforce consultants
git blame
Haha first things I did once I saw this. The repo belonged to a different team, and the contributor left long ago. Looks like they were the only one active in it for a while, which makes me question why they didn’t simply remove the check lol. We do pretty strict reviews here, so this must’ve been way before the reviewers requirement was placed - for this repo at least. Edit: After reading the comments, turns out SFDC enforces this code coverage to push to prod. Didn’t know that!
The check is automatically enforced by Salesforce PROD instances, so this is a bypass to get code in to PROD without having to write/update a test class Tbh I’ve done it before to force a hotfix on a weekend, but would always fix it Monday as it’s pretty shameful shit 🙈
> this must’ve been way before the reviewers requirement was placed this must’ve been WHY the reviewers requirement was placed
> this must’ve been WHY the reviewers requirement was placed If it was, the repo would have already been removed. Since it wasn't, clearly nobody knew about this.
He's fired. You're lead detective now. Congrats, kid.
>contributor left long ago Wonder if they are at Twitter now...
That hiring by lines of code was real?🤣
This is what extreme hardcore coding looks like
Previously worked actively in the Gaming (the System) field.
There is no real advantage to gain from removing, but removing would hurt code coverage metrics. Presumably management still cares about that.
Each of the thousands of lines is a different developer, single commit each.
ChatGPT has seen this code. And at some point will implement it.
I did see a post where chatgpt typed i++; like 5 times instead of i+=5; As far as i can say the multiple line thing isn't a better option in c++.
> As far as i can say the multiple line thing isn’t a better option in c++. You’re right. Any modern C++ compiler would optimize them the same way.
He’s doing his fucking best, okay?!
Okay!
It gave me a piece of code similar to this instead of just using a loop once lol. It was like 100
"Now make it good"
I have literally said shit to it like that before lol sometimes that works.
I unfortunately found something similar- biggest file around by a factor of 50. Sad days.
An old coworker of mine did something similar. He got stuck on an app that a bunch of people had basically shat out over several years, and like a week after he got stuck on it, the team decided they needed 90% coverage for all their apps. He was like this is fucking impossible, to which the manager promptly responded your problem not mine. So he wrote a bunch of unit tests that called all the functions, caught every exception, and did no validation, just did `assertTrue(true)` at the end. He wasn't proud of it, but his job was on the line, so I don't blame him.
We had an API like that. Huge pressure from management to make it performant under load, so dev built a load tool to send thousands of requests and measure response times. They got a nice reward for demonstrating that the current infrastructure was good for contracted service times at nearly twice the projected load. I got no reward when I demonstrated that their tool didn't verify the response properly, so at 30% or higher loads, the API responded quickly with a "no service" message, that they were incorrectly classifying as SUCCESS. It basically stopped working, but at least it gave an error message within the projected response time. Be careful what you measure. That's exactly what people will work to give you.
One of our API's here at work got a requirement to have max half a second response time. Apart from a very few exceptions, I knew that it delivered way inside that, usually within 50ms. Then I got a report from CTO saying that most took 1-2 seconds to respond, including what's basically an echo service *(it reads the token and responds with the token's content in a readable format)* that's normally 10ms reported as 1.4 seconds. After a lot of back and forth I found out how the report was made. Big java framework, ran on an old machine, from *India* over who knows what lines... Got them to run the test from a local, beefy machine instead and suddenly the numbers were muuch better. Must be magic.
Yes, this is similar to what I've seen with people running sql locally, and complaining that it was taking a long time, but it turns out they were selecting a large amount of data over a VPN. Server handles the query just fine, but the raw transfer made it seem like the query was taking up to a minute.
Huh? Hitting all the branches is like 3/4 or more of the effort, then you just have to assert whatever came out the end when running it. Seems to me like asserting true at the end is just sticking it to them for making an arbitrary code coverage requirement?
Lol not if it it's dirty code, not even close. A lot of it can be impossible to legitimately unit test without refactoring the entire code base.
I wasn't there for it, but he didn't exactly hit the branches gracefully based on what he told me. It was literally cobbling things together until a branch got hit. If the data was wildly off, he didn't care. The `assertTrue` was because the code scan tools would flag the tests if they didn't have any assertions, although sticking it to them certainly wasn't outside of his wheelhouse either.
FeelsBadMan
Seen this before in the wild too. This is to get around the code coverage requirement for production code in Salesforce.
Can you imagine their codebase if getting 75% coverage is that tough? Dear lord.
The problem usually comes in when this requirement is added to a pre-existing code base that has never had a coverage requirement before. You could stop feature work for a few weeks to catch up and make the numbers right but management isn’t gonna allow that, you need to keep shipping code…so you pad the coverage to 75% to get a deploy out he door and tell yourself you’ll come back and right the real tests later. But now you don’t have any time budgeted to do that because “well we’re already at 75%”. I haven’t done this exact tbh if before but I’ve done shit that was this stupid to meet an arbitrary target on an unrealistic deadline that Cannot Be Moved
Go ahead and change the file extensions and ratio as needed: % for i in $( seq $(echo $(echo $(for f in $(find . \( -name \*.c -o -name \*.h \)); do wc -l $f | cut -d' ' -f1 | tr '\n' + ; done)0 | bc)'*75/100' | bc ) ); do echo i++\;; done > /tmp/filler.c
Did you unit test this?
I’m guessing Salesforce? We had a merger with a company that had such a huge single class that adding enough I++ to it to pass the coverage for a fix to a company stopping bug exceeded the file size. But you you make the whole class 1 line
Dude, that’s genius. I wonder if sonar would actually catch this?
I’m gonna try this later on a repo I own LOL
update please LOL
I am also interested in the results LOL
So did it work LOL?
We still don't know LOL
Maybe he died LOL
if it does just mark it as a false positive
Encode it with XOR cipher
And that’s why code review is important, kids!
That's also why having a bullshit metric just to have one is a problem. Clearly someone just wanted to see the build box report 75+% coverage, and the devs satisfied the requirement.
Yeah I never liked code coverage, especially applied to legacy code bases where it can be nigh impossible to get certain parts unit testable. “When a metric becomes a target, it’s no longer a good metric” or something to that effect.
I feel like the root problem is that lines of code is a technical metric. Too many non-technical people think that more lines of code automatically means more stuff is getting done. A programmer can add 10 lines of really important code and have added far more value than a guy mashing 1000 lines a day.
"Would you rather read a ten page novella or a 100 page dictionary?"
100% Code coverage is not an indication of well tested code, but 10% code coverage is an indication of poorly tested code. Use the metric for what it's purpose is.
One of those gets paid by line of code models, huh?
I had a colleague who should be paid by character because I found several things like this: ``` If var = "something" or var = " something" or var = " something " or var = "something " Then ' code for something End If ``` ( Yeah... , in VBScript, because the language alone is not bad enough ) he also didn't use arrays, functions or objects, some files have more than 9000 lines
>had what happened to this very competent fella
Him? Why, he was *promoted,* of course!
r/maliciouscompliance
[удалено]
How does this pass code coverage? What is it covering exactly?
Code coverage is how much of the code is executed (covered) during testing. Pretend you have 10 functions, each with 5 lines of code, and somehow no other code in the project. If your tests call 1 of the functions, you have 10% coverage. If your tests call 2 of the functions, you have 20% coverage. And so on... Now let's say you have three functions, one called `fakeCoverage()` with 10 lines, one called `realWork()` with 10 lines, and one called `notCovered()` with 10 lines. The first two are called during testing but the last one is not. Your code coverage is therefore 2/3 or about 66.67%. Say you add 10 more lines of code to `notCovered()`. Your code coverage has now gone down to 50%. But if you add 20 more lines to `fakeCoverage()`, suddenly it's back up to 66.67%.
Therein lies the logic which led to this abomination.
3 lines of this for every line of real code actually added
To my understanding code coverage is code that is tested/has unit tests. So they add 3 lines of code to a spot that's untested and 20 lines to this fake function and fix the test to pass for the new lines. So that way 75% or more had test coverage.
If Elon was his boss, he’ll be getting a promotion for the lines of code
[удалено]
Are they sentient?
Are they salted?
Elon can’t write a loop anyway, so I’m certain this would pass.
I have seen no evidence whether or not Elon can write a loop. I have seen evidence showing that Elon CANNOT write an if statement. https://twitter.com/elonmusk/status/1629633384338149378/photo/1
I never understood this, assuming code reviews, what are the chances of two people willing to cooperate on something like this, and not already been fired? …. Then this past week happened. I came back to a project to find CI broken. Among many other shenanigans, one dev got a manager to disable the CI check so he could merge anyway, and this manager rubberstamped the code review, no technical review at all. WTF
This likely isn’t the result of a malicious bunch of programmers. More likely some C-level dork decided that all repos need to have 90% code coverage, and that was impossible for a legacy repo. Easier to do something like this to make the C-level happy than to try to fight your way up through the chain of command to explain why the policy is dumb.
Salesforce?
Salesforce.
Missed a golden opportunity here to create middle finger ASCII art.
can someone explain? I don't do programming professionally
ELI5 version is code coverage = (number of lines your test cases hit)/(total number of lines). This company says code coverage must be 75% or better (3 of every 4 lines are tested). Someone had less than that. Instead of writing more tests (what you're supposed to do), he added one test and a bunch of nonsense lines, not improving anything.
For some reason, all I feel is respect.
this is the answer
I'm 99% sure this was me! I had to deprecate your code base from a prod environment for a client and Salesforce kept giving me shit about meeting 75% code coverage, even after I commented out/deleted the entire class. Made no sense to me how to cover something that didn't exist. Your rep didn't respond to a single email trying to give him a heads up and ensure everything would be good so I had to wade off into this shit by myself with no clue what impacts there would be. Obviously it's tied to your repo, which I wasn't aware of. It was midnight, I had deprecated most of the package, and I was down to like 8 or 10 pieces of Apex code that simply wouldn't uninstall because of the dependencies. Thus, this horrific act of code was born. *And it didn't even fucking work.* I ended up doing the smart thing at the end, which was deleting every piece of code through the CLI all at once.
Create stupid metrics, get stupid code.
Something like that happened at my current place of employment a while before I joined. The guy was fired and sued
>The guy was fired and sued The guy that enforced a metric and didnt bother checking any further or the guy sleeping on all his code reviews?
> The guy was fired and sued Fired i understand. But the fuck did they think suing him would do? Clearly this code (kind of thing anyway) doesn't introduce any vulnerabilities. All it does is take up some hdd space, at best. And if it's being excluded from release compilations (which is super likely), it isn't even being *used* in the product. If the guy was given a metric for commits, he was *meeting the requirement*. Not his fault if the company was implementing a *stupid* metric. Depending on what the suit was specifically claiming, easy win on his part.
Not that coverage padding is good but it's kinda their fault for not having the code review needed to catch the guy
r/programminghorror
Someone call Elon
[удалено]
Omg. I’ve seen this so many times. Is it salesforce code?
I love it! Code coverage is such BS. There are way better metrics to keep track of.