[mdip]

I commented more extensively in the root of the post, but you can't even begin to imagine.

Think about every script you've ever written for "some thing at home" and how you only cared that it worked for the very narrow, specific, circumstances you were looking for. Maybe you left out error handling and just let it crash when you failed to put in the right parameter. Who cares? It's just a script for your one, lonely, workstation/server.

That's about the quality we're talking about. The companies that make these switches sell them to, maybe, five customers[0]. Software upgrades? Sure, if you replace that $30,000 card with the new version. Having trouble with the software? A support contract can be purchased for a similarly high fee[1]. A company producing this equipment doesn't put a lot of money into QA. In security, there was a general fear about these programs. It was so concerning that the management interfaces to the equipment was on "as close to air-gapped as you can be without being air-gapped" networks with the kinds of logging, auditing and the likes that you'd expect for a network holding government classified information[2].

[0] So few customers, in fact, that you can call them up with a serial number and find out who the purchaser is. I know this first hand due to someone propping the door to the switch site open resulting in, I think, 5 of what I was told were $30,000 a-piece cards being stolen. I was told they were effectively worthless to the thief, though, because nobody would buy them second hand in that manner and the moment they were offered for sale, if someone realized what they were, the thief would be caught.

[1] To be fair, I know of one specific circumstance where the company only offered paid support but that was mainly because I didn't work on that team; I'd speculate that all of them functioned this way.

[2] Well, maybe what you'd expect in an ideal world, anyway.

[archon]

> Think about every script you've ever written for "some thing at home" and how you only cared that it worked for the very narrow, specific, circumstances you were looking for. Maybe you left out error handling and just let it crash when you failed to put in the right parameter. Who cares? It's just a script for your one, lonely, workstation/server.

I find seeing this mentioned oddly comforting. I write my worst software for myself. Zero validation, very little error handling, unchecked assumptions all over the code.

At least I'm not the only one out there with a barely-stable home lab setup because of shoddy programming.

[gmueckl]

This is the difference between tinkering, experimentation and engineering. All of these have their proper place. There is no shame in having a shoddy piece of code as long as it is within a lab environment. Trouble usually starts when this kind of code changes hands and finds serious users.

[mdip]

I joke that I have an ever growing private repository of code I'm too embarrassed to publish publicly. Only partly joking; it's actually several repositories. But as others have said, people who are programmers more than just professionally do this all the time. There's very few things that involve using a computer that I run into day-to-day that I don't think, "I could do this faster with a dirty script[0]"

I used to do interviews and would often encounter candidates who had no public repositories, anywhere, GitHub or otherwise. I learned quickly to be very disarming before even asking and settled on something along the lines of "Look, I know when you write things for yourself, you're doing it with very limited time and for an audience who is more interested in it doing 'The Thing' without regard for anything resembling best practices, or even typical practices. I fully expect lousy code and that's perfectly fine, but I really need as many recent samples as you can possibly give me before this evening to be prepared.[1]"

What wasn't probably realized by the candidates was that if I'd made that phone call they were getting the technical interview regardless of the code quality and I was barely going to glance at their code until the interview. And the best thing they could do for me was to give me code that was on the bad side of things[2]. The first question I'd ask is "OK, imagine you have all of the time you'd ever need to make this perfect. The goal is to get there in stages and maximize the improvements as early as possible. What would you change and in what priority." There's no way in their development career that they're not going to encounter something as awful as they've written in production and be asked to fix it, and they're going to have to start with "make it work again" and in a limited number of stages "get it to the best state; hopefully to an ideal state" but the goal is to get to as stable of a state as possible before you're pulled somewhere else.

[0] Or better, stop doing it at all by putting that dirty script in a cron job that won't have any logging, I'll probably be really happy with for the first few weeks, then forget it was there and not realize a few months later when it stops working.

[1] It was kind of a dick move and I always felt a little guilty, but I know that my instinct would be to spend an evening cherry picking the best examples which I'd then go without sleep to clean up as best I could before morning. And it wasn't a situation where I wanted to judge them at their worst "Well, if their worst code looks this good, they must be good."; if I got a code sample that was too good, I figured it was the rare script that was cared about but that the developer didn't want to unleash on the world and feel like they had to support. When this happened, it was always from a candidate who gave me one maybe two things while claiming to be a code addict and I always asked those candidates to rectify their love for software with only having a couple of very small, albeit well-written code samples. I recommended one guy who admitted he had a lot of other code but was too embarrassed by it and then logged into his BitBucket repo.

[2] Which I found worked best when I simply just asked candidates for their worst code and told them, generally, that I'd like to get a feel for how they handle eliminating technical debt. If the code was too good, I'd have to find something that I felt they should be able to quickly understand well enough to offer ideas for improvements; that rarely worked out well -- it's always easier on the candidate when it's code they've written because they're, at lease possibly, likely to be familiar with it.

[indigochill]

To [0], would there be any value to stealing the cards not to sell them but to reverse engineer them to find vectors for attacks? "Effectively unsupported, never updated, and responsible for a massive amount of telecommunications" sounds like a great time for an attacker. Also seems like it would have value for industrial espionage.

[mdip]

I can't say that I'm completely sure, but I'm going to guess the answer is "Probably Not". The big telecoms tend to be very conservative about where they spend their money -- understandable with a product this expensive despite the grief one tends to have in working with the product. The market is also moving toward more generic equipment and less specialized hardware for a lot of things and I'd imagine these cards will fall into that category at some point, as well.

[blacksmith_tb]

What keeps most of from 'shipping' our home-grade, hacked-together code to anyone else is the fear of having to support it, though. "OK, grandma, now shell into the RPi and tell me what crontab -l says..." - you would think that aside from any sort of professional ethics (or even pride) that companies in these situations wouldn't dare ship something that 'mostly worked' (unless they had superhero lawyers...)

[mdip]

LOL - I'm reading this as I'm checking my home nagios server to see why I just got an e-mail about the Raspberry Pi at my parent's cabin up north.