7 ms·

I'm a recovering security guy. When I listen to security people rant, I can see their points and it's a bit of fun, I like a good rant. But I get the impressi

I'm a recovering security guy. When I listen to security people rant, I can see their points and it's a bit of fun, I like a good rant. But I get the impression that they're continuously discovering new and exciting ways that individual facets of individual pieces of software (and the processes around them) suck. All without ever accepting that the entirety of the software ecosystem sucks (and that they're rarely moving the needle on that front). All software and the internet combined is a giant ball of mud that just grows and grows as more people add onto it. There's no architecture more than the strict minimum to keep the whole thing from falling apart the moment someone breaths too heavily near it. And that's not even including when commercial interests keep trying to design their chunks of the mudball in unique ways that make themselves more money at the cost of everyone else's chunk getting more complex. Like everyone else adding mud, security wants to get in, hit their requirements, and get out. I just don't like the chip on their shoulder that nobody else is doing enough to fix the system throughout in a way that helps them achieve their goals with the least fuss.

platz 7y ago
Not really security, but regarding software in general, Mud is one of the reasons I gravitated torwards pure FP languages. It doesn't solve everything, but the added guarantees help shift some of the cognitive burden away from having to dig into every method to have to see what's going on, and I can spend that mental budget elsewhere.
- TheFiend7 7y ago
  Maybe FP forces some degree of added conformity to the code. But I find code maintenance and readability has more to do with the person writing it than the tool they used IMHO. FYI I am in fact an FP fan, and I use FP principles in a large amount of my code. But I've seen some seriously convoluted and confusing FP code just like I've seen behemoths of objects with twisted internal state manipulation balancing on blind assumptions and false guarantees of order.
- FpUser 7y ago
  This reminds me that "but think of the children" mantra. From my observation programmers often tend to justify / promote their languages/tools/etc under pretense of solving security problems.
  - platz 7y ago
    "Not really security"
- deleted 7y ago
  [deleted]
Asooka 7y ago
I don't understand what "accept" is meant to mean here. If we accept that everything sucks, the only thing left to do is leave the field, since it will always suck no matter what we do. If we try to make it better, then we're not accepting that it sucks. I think there is a better way to phrase what you mean.
- Aeolun 7y ago
  You kind of need to accept that it sucks for you to want to make it better. If you thought it was already perfect there would be no reason to.
  - rhizome 7y ago
    The problem is interpreting what "it" means when someone says "it sucks." All software and the internet, like GP uses it? I don't think that's a fruitful line of thinking.
    - Aeolun 7y ago
      From experience I know it’s not all, but very close to 99%
  - mike_max 7y ago
    you can acknowledge that it sucks, refuse to accept it and try to make it better
- deleted 7y ago
  [deleted]
- majormajor 7y ago
  Leaving the field won't help, the whole damn world sucks. You have to accept that there's no perfect alternative out there, you won't tomorrow magically find a system with no flaws, and system design is hard because the world is constantly changing and you don't have perfect information. If you just chase "something better" because you can't accept things, you'll continue to be disappointed. Once you accept it, you can start trying to make your little corner of the world better. Not perfect, but better. It's more satisfying than shouting into the void.
draw_down 7y ago
Yes, this post has an apparently-unearned righteousness to it. You can get mad when you’re sitting in traffic if you want. Feel free to emphasize precisely how pissed off you are! But you’re still traffic.
dehrmann 7y ago
> I get the impression that they're continuously discovering new and exciting ways that individual facets of individual pieces of software (and the processes around them) suck As a software engineer, I think this is my experience at every job I've had around systems in general.
- sowbug 7y ago
  <OT> As a person sometimes overly distracted by grammar, I would like to thank you for using the "As a [description of subject], [subject] [rest of sentence]" construction correctly. Getting this wrong, which is called a "dangling modifier" error, is common. Examples from today's front-page HN discussions: As a new (1 year) coder starting out at 39 years old, this sounds very similar to the path I envision for myself. As another former Googler, yes, searching the entire monorepo was a frequent occurrence. Corrected: As a new (1 year) coder starting out at 39 years old, I envision a very similar to the path for myself. I'm another former Googler. Yes, searching the entire monorepo was a frequent occurrence. </OT>
  - greedo 7y ago
    If you're going to pedant, at least fix your first "correction" so that it includes its subject.
    - sowbug 7y ago
      Ha! You got me. Poor editing. Please delete "to the" in the corrected example. (or maybe I was just adhering to Muphry's law https://en.wikipedia.org/wiki/Muphry%27s_law. https://en.wikipedia.org/wiki/Muphry%27s_law.)
  - YeGoblynQueenne 7y ago
    I read the examples of dangling modifiers you give as assuming "Speaking" at the start of the sentence. So, e.g. "Speaking as a new (1 year) coder ... this sounds very similar...".
    - 7y ago
MrBuddyCasino 7y ago
> and that they're rarely moving the needle on that front This is key. They're not the ones pushing to replace C/C++, even though you'd think that would logically follow. In that way, infosec is the DEA of IT.
- quantumfoam 7y ago
  I'm supplying a +1 for this comment because it's hilarious to think of our industry as useless as the DEA.
lidHanteyk 7y ago
There is a paper on "balls of mud" that I feel is essential reading for our discipline. http://www.laputan.org/mud/ http://www.laputan.org/mud/
- tanseydavid 7y ago
  Thank you for reminding of this paper. It is fascinating to me that the content (written 20 years ago) reads like an up-to-the-minute description of the madness of IT today. The continual repetition of anti-patterns is so widespread and commonplace that it is clear to me that expediency will almost always win-out against any engineering prudence. Expediency gets assigned highest priority -- typically without any real reasoning. The negative effects accrue slowly but consistently -- and correcting for the shortcoming gets consistently more difficult. The condition is then self-perpetuating.
rymohr 7y ago
I hate when I see people throwing in the towel like this. As a two developer company with four separate products doing nearly $500k in ARR collectively, Kumu [1] is a living example that it doesn’t have to be this way. We rely heavily on bash, docker and cloudformation. We only use Ubuntu LTS and we lag a release behind so there are plenty of tutorials available when it comes time to upgrade. After experimenting with backbone, coffee script, flow, vue and multiple redux libraries we’ve settled on rewriting everything in typescript and developing our own thin redux abstraction. Embrace new tech that makes developers’ lives easier while hopefully making things more secure too. I get it if that’s not possible in large enterprise companies, but please don’t throw all software under the bus. Software is and will always be fun and there are still fun companies to work for if you’re willing to take a little risk. [1]: https://kumu.io https://kumu.io
- pg_is_a_butt 7y ago
  "MRR per year".... hilarious. I personally make over $1MM every single day per decade
- finnthehuman 7y ago
  I'm a bad writer. I'm not trying to throw in the towel, say software can't be fun, or that useful products can't be built within the status quo. I can look at the product I develop and rattle off an impressive list of capabilities, talk about how well it is designed, say why it's the best product for the job on the market and talk about successes in the field. But I can also look at it and see a laundry list of design flaws, architectural limitations and unrealized enhancements that may never get time on the schedule. The second side of the fence exists, and security people inherently spend a lot of time there. Spend enough time there and you see how the system that is the sum of all software is a mess. I'm not even saying it's a bad thing, just that it's the inescapable reality. Your architecture is like swimming in a school of fish. By moving with the group you benefit from the successes of the group. Ubuntu, docker, typescript and delivering your product as webapp brings a lot of benefits in featureset, maintenance and training that come at a reduced cost. For the same reasons I also prefer to use as much popular off-the-shelf tooling as possible and stick to familiar designs wherever possible. You're probably doing better than most. But even with all that benefit, the components of your system are fraught with defects and limitations that in a perfect world would already be solved problems. Both in the stack you use and your own software. And you make it work despite that. Great. That's not my point.

platz 7y ago

Not really security, but regarding software in general, Mud is one of the reasons I gravitated torwards pure FP languages. It doesn't solve everything, but the added guarantees help shift some of the cognitive burden away from having to dig into every method to have to see what's going on, and I can spend that mental budget elsewhere.

TheFiend7 7y ago
Maybe FP forces some degree of added conformity to the code. But I find code maintenance and readability has more to do with the person writing it than the tool they used IMHO. FYI I am in fact an FP fan, and I use FP principles in a large amount of my code. But I've seen some seriously convoluted and confusing FP code just like I've seen behemoths of objects with twisted internal state manipulation balancing on blind assumptions and false guarantees of order.
FpUser 7y ago
This reminds me that "but think of the children" mantra. From my observation programmers often tend to justify / promote their languages/tools/etc under pretense of solving security problems.
- platz 7y ago
  "Not really security"
deleted 7y ago
[deleted]

Asooka 7y ago

I don't understand what "accept" is meant to mean here. If we accept that everything sucks, the only thing left to do is leave the field, since it will always suck no matter what we do. If we try to make it better, then we're not accepting that it sucks. I think there is a better way to phrase what you mean.

Aeolun 7y ago
You kind of need to accept that it sucks for you to want to make it better. If you thought it was already perfect there would be no reason to.
- rhizome 7y ago
  The problem is interpreting what "it" means when someone says "it sucks." All software and the internet, like GP uses it? I don't think that's a fruitful line of thinking.
  - Aeolun 7y ago
    From experience I know it’s not all, but very close to 99%
- mike_max 7y ago
  you can acknowledge that it sucks, refuse to accept it and try to make it better
deleted 7y ago
[deleted]
majormajor 7y ago
Leaving the field won't help, the whole damn world sucks. You have to accept that there's no perfect alternative out there, you won't tomorrow magically find a system with no flaws, and system design is hard because the world is constantly changing and you don't have perfect information. If you just chase "something better" because you can't accept things, you'll continue to be disappointed. Once you accept it, you can start trying to make your little corner of the world better. Not perfect, but better. It's more satisfying than shouting into the void.

draw_down 7y ago

Yes, this post has an apparently-unearned righteousness to it. You can get mad when you’re sitting in traffic if you want. Feel free to emphasize precisely how pissed off you are! But you’re still traffic.

dehrmann 7y ago

> I get the impression that they're continuously discovering new and exciting ways that individual facets of individual pieces of software (and the processes around them) suck As a software engineer, I think this is my experience at every job I've had around systems in general.

sowbug 7y ago
<OT> As a person sometimes overly distracted by grammar, I would like to thank you for using the "As a [description of subject], [subject] [rest of sentence]" construction correctly. Getting this wrong, which is called a "dangling modifier" error, is common. Examples from today's front-page HN discussions: As a new (1 year) coder starting out at 39 years old, this sounds very similar to the path I envision for myself. As another former Googler, yes, searching the entire monorepo was a frequent occurrence. Corrected: As a new (1 year) coder starting out at 39 years old, I envision a very similar to the path for myself. I'm another former Googler. Yes, searching the entire monorepo was a frequent occurrence. </OT>
- greedo 7y ago
  If you're going to pedant, at least fix your first "correction" so that it includes its subject.
  - sowbug 7y ago
    Ha! You got me. Poor editing. Please delete "to the" in the corrected example. (or maybe I was just adhering to Muphry's law https://en.wikipedia.org/wiki/Muphry%27s_law. https://en.wikipedia.org/wiki/Muphry%27s_law.)
- YeGoblynQueenne 7y ago
  I read the examples of dangling modifiers you give as assuming "Speaking" at the start of the sentence. So, e.g. "Speaking as a new (1 year) coder ... this sounds very similar...".
  - 7y ago

MrBuddyCasino 7y ago

> and that they're rarely moving the needle on that front This is key. They're not the ones pushing to replace C/C++, even though you'd think that would logically follow. In that way, infosec is the DEA of IT.

quantumfoam 7y ago
I'm supplying a +1 for this comment because it's hilarious to think of our industry as useless as the DEA.

lidHanteyk 7y ago

There is a paper on "balls of mud" that I feel is essential reading for our discipline. http://www.laputan.org/mud/ http://www.laputan.org/mud/

tanseydavid 7y ago
Thank you for reminding of this paper. It is fascinating to me that the content (written 20 years ago) reads like an up-to-the-minute description of the madness of IT today. The continual repetition of anti-patterns is so widespread and commonplace that it is clear to me that expediency will almost always win-out against any engineering prudence. Expediency gets assigned highest priority -- typically without any real reasoning. The negative effects accrue slowly but consistently -- and correcting for the shortcoming gets consistently more difficult. The condition is then self-perpetuating.

rymohr 7y ago

I hate when I see people throwing in the towel like this. As a two developer company with four separate products doing nearly $500k in ARR collectively, Kumu [1] is a living example that it doesn’t have to be this way. We rely heavily on bash, docker and cloudformation. We only use Ubuntu LTS and we lag a release behind so there are plenty of tutorials available when it comes time to upgrade. After experimenting with backbone, coffee script, flow, vue and multiple redux libraries we’ve settled on rewriting everything in typescript and developing our own thin redux abstraction. Embrace new tech that makes developers’ lives easier while hopefully making things more secure too. I get it if that’s not possible in large enterprise companies, but please don’t throw all software under the bus. Software is and will always be fun and there are still fun companies to work for if you’re willing to take a little risk. [1]: https://kumu.io https://kumu.io

pg_is_a_butt 7y ago
"MRR per year".... hilarious. I personally make over $1MM every single day per decade
finnthehuman 7y ago
I'm a bad writer. I'm not trying to throw in the towel, say software can't be fun, or that useful products can't be built within the status quo. I can look at the product I develop and rattle off an impressive list of capabilities, talk about how well it is designed, say why it's the best product for the job on the market and talk about successes in the field. But I can also look at it and see a laundry list of design flaws, architectural limitations and unrealized enhancements that may never get time on the schedule. The second side of the fence exists, and security people inherently spend a lot of time there. Spend enough time there and you see how the system that is the sum of all software is a mess. I'm not even saying it's a bad thing, just that it's the inescapable reality. Your architecture is like swimming in a school of fish. By moving with the group you benefit from the successes of the group. Ubuntu, docker, typescript and delivering your product as webapp brings a lot of benefits in featureset, maintenance and training that come at a reduced cost. For the same reasons I also prefer to use as much popular off-the-shelf tooling as possible and stick to familiar designs wherever possible. You're probably doing better than most. But even with all that benefit, the components of your system are fraught with defects and limitations that in a perfect world would already be solved problems. Both in the stack you use and your own software. And you make it work despite that. Great. That's not my point.