Siemens contractor hid "logic bomb" in complicated spreadsheet, guaranteeing future maintenance work

Originally published at:


Planned obsolescence is a widespread practice in the industry, Siemens is no doubt guilty of designing products made to fail. If the engineer would have been a little more coy he could have come up with an acceptable way to implement the scheme, maybe query the version of software running and “fail to run on incompatible software” or limit the CPU frequency because the battery is old (cough apple).


“Logic Bomb” and “Spreadsheets” are two things that should not be in the same sentence, but thank you for that, Excel…


Yeah, interestingly he’s not charged with fraud but “intentional damage to a protected computer.”

Sounds DMCA-related, but dunno for sure.

Also, very embarrassing for the world to discover that Siemens is running its sales pipeline with spreadsheets.


CPU throttling was better than the alternative, which was unexpected shutdowns.

Let me elaborate: Apple’s throttling kicked in after unexpected shutdowns started happening, meaning the battery was already shot. That’s the opposite of planned obsolesence: they’re trying to get a longer lifespan out of it. Most people didn’t even notice the throttling because the phone was a few years old and already becoming obsolete performace-wise. That, and by design very few things outside of benchmarks peg the CPU on a mobile device.




Actually, it kept the phone from being obsolete by allowing it to continue working for more than 20 minutes at a time. Sure, you couldn’t use the latest greatest apps – and Apple SHOULD have said this is what they were doing because, in the end, they ended up being penalized for allowing a product to work longer than it should have. Not to get into the design of internal / external batteries and otherwise. I always carry a few chargers for my devices and I’ve known for years that a plugged in iDevice worked better while on a charger. IF you wanted performance that is. Most of the time, didn’t matter.


Amateur. The nature of information technology is such that if you put the same amount of effort into guaranteeing that you’ll put yourself out of a job you’ll still end up being called back by the client again and again and be treated and paid like a hero for it.


Did he by chance also happen to work on the Airbus 350? Sounds suspiciously similar to that 149 hour issue…


Plus, it’s not like it was going to be bug free otherwise.


The guy should have gone into manufacturing farm equipment where this kind of thing is tolerated.


That’s the 1980s law that’s supposed to apply to major government, financial and corporate mainframes. Now it covers practically any PC connected to the Internet.

eta: It really needs to be refactored back to sanity, but they’re loving it too much. Wait until some corporation gets nailed for monkeying with a “protected” Internet of Shit device. (If you make orders via your Alexa, it would certainly qualify as a protected computer.)


So, it’s not like:


It’s a pretty common practice as far as I can tell - I spent an entire year doing “contract programming” for a finance company, catching and patching logic bombs in an application their business was dependent on, while their in-house team worked furiously to build a complete replacement from the ground up.

In their case, a former department head had been handed a large budget, told “and here’s your team of in-house programmers, now build us an application that does the stuff in this requirements doc”. So they took all of the money, handed it to their good friend who ran a software company, and said company built a 10-million line mess of deliberately obfuscated perl code with zero documentation (that was provided to the client, anyway), and gave their rates for updates and bug fixes.

The exec was fired, and I was not allowed to hear about how that was going since legal proceedings were still in progress, and I was hired on for what they calculated was about 1/10th what the software company was demanding to fix their own errors. I started the year with 10 million lines of gibberish, and at the end I had only 1 million lines of perl code, (half of which was still gibberish), and a six-inch thick stack of documentation of intentional crash code (for their lawyers), my favourite of which was the part that generated a random number between 1 and 8003, iterated that many times generating additional random numbers, and if any of those random numbers matched the current unix date stamp, it caused the whole program to exit. Otherwise, it would return a 2.


So when a private contractor does that it is a crime but when Accenture does something similar it is called keeping the pipeline full?


True artists are never celebrated in their time.


During my 30 years as a programmer, I was often sorely tempted to do these kinds of things. And the longer you work for an individual company, the more you know about their procedures for locating and fixing crashes. Hell, I wrote lots of those procedures. And that meant that I knew how to add code that would never be found by anyone who didn’t want to read 10,000 lines of code, which no one does.

The goal wouldn’t be to guarantee work, but to punish a company preemptively for laying me off. Basically, there would be a timed crash condition that I could keep pushing forward as long as I kept working. Once you get laid off for the 4th time for no reason other than bottom line, or because your last name didn’t match the owner’s, these things get VERY tempting.

So, no, I never did any of it, despite ridiculous autonomy and lack of supervision and cross checking, and I last got laid off 7 years ago, so I’m retired with good money.

But I get it.



An applicable, sociopathic commentary from Marty Kaan (from the criminally underwatched “House of Lies”):



I once got laid off because the owner paid someone to cast his company’s horoscope and it was bad.


Too often because someone will decide later to “tweak” it, and there’s no documentation. But even if there is, it won’t be used. I once was tasked with planning and creating procedures for long-term support of a product. I asked the head programmer what kind of documentation he would want. He gave an answer that I later found is almost universal among software people: “None. I know what I’m doing. If I need to know how something works I’ll just read the code.”