Intention matters greatly in situations where someone is doing something which may be interpreted as duplicitous.
This is someone who is in a situation that not many people have experienced. He has the integrity to think out loud about his actions and bring them into question for himself and others.
I think he should come clean about the automation to his employer (he doesn't have to say its been going on for 6 months, of course). Unless the employer is a total ghoul, it is unlikely that this would get him into trouble.
If the story is true, the guy is NOT a fraudster. There are vastly more unethical things to worry about than a clever guy who puts VBA macros to good use.
I would bet most companies are interested in reducing "waste" by not hiring people no longer needed. The way the OP talks about the company, it seems like they have no need for actual developers.
It's also the correct word; he is seeking to obtain value from another party by material misrepresentation of the facts.
> I think he should come clean about the automation to his employer (he doesn't have to say its been going on for 6 months, of course). Unless the employer is a total ghoul, it is unlikely that this would get him into trouble.
Well, without the intentional introduction of errors, I would agree with you. With that, I think lots of employers would say “Good job on the automation, but you are terminated, for cause, for the deliberate sabotage.”
> If the story is true, the guy is NOT a fraudster.
If the story is true, the guy chose to become a fraudster as a precaution against the risk that the automation might not be appreciated.
He could just say: "...hey, I've been working on automating this task, I think I got it working now."
One is the deliberate insertion of errors. He should stop doing that. That's not cool. (I wouldn't label it as "fraud" though.) If the employer found out about that, they'd be well within their rights (legally, ethically, whatever) to fire him over that point alone. However, it doesn't sound like the intentional errors are any more than what would naturally occur if he hadn't automated the system, so the end result is unchanged, so while I won't give him a pass on it, I also can't demonize him for it.
The other is having built an automation tool without telling his employer, drastically reducing the amount of time it takes to do his work, and then not having other work to take on to fill his time.
To me, at the heart of it is whether he's being paid for his time, or if he's being paid to get a specific job done. It sounds like it's the latter (and I would say that's the case in any salaried position), so while the company might be annoyed/pissed that their estimate of the time needed was way off, that's really their problem, not the OP's.
We wouldn't be having the same discussion if he didn't automate, but just got more efficient at the job because he'd done it for a while. So say initially he had to work 40 hours a week to get it done, but after 6 months on the job he was able to drop that down to 35 hours a week due to familiarity with the work. Why is it ok to work 5 hours less but not 38 hours less, while still getting the same job done?
Fraud, though? No. The only way it would be actual fraud is if he were getting paid hourly, and he was marking up a time sheet with 40 hours when he really only works 1-2. But it doesn't sound like that's the case here.
They hired him to do a job. He's doing the job. But because of a lack of trust, he isn't telling them that a little devil in the form of a VBA macro is helping him immensely.
The more I think about it the more I align with the OP clamming up and enjoying the ride until he finds something better-- or perhaps until he develops enough trust to be able to reveal the automation.
The biggest hazard, aside from loose-lips, is that the company could hire a 22-year-old business analyst who might quickly report back that Excel can do a few more things than they thought. Then the 22-year-old will look like a genius and the OP will look like a blockhead.
There is some manipulation going on, but there seems to be a difference between submitting a code review with bugs inserted on purpose, and shipping code with bugs inserted on purpose.