9 ms·

Couldn’t this end up being disaster with a large codebase and even a small amount of turnover? Are you really advocating that someone should write all their dep

Couldn’t this end up being disaster with a large codebase and even a small amount of turnover? Are you really advocating that someone should write all their dependencies themselves even if they can afford it?

alibarber 6y ago
It depends on the context. Yeah it'd be lovely to have your system connected to the internet - but no, our clients wouldn't give us money if you do that, and we need money. So, maybe yes in this case, start writing some quality, well thought out maintainable libraries (that can include audited third party code), and just bill it. In my case, the cost to the client of a team of devs working on that was less than the cost to them of the risk of a film leaking... [Edit] - But what I have found through experience is that the code that was written under these constraints seemed to be better, more secure and robust, than without them. YMMV.
jrumbut 6y ago
I assume if you have the money to be that thorough you have the money to offer some inducements to stick around. Plus if all you know is this custom stack, where are you gonna go?
- Godel_unicode 6y ago
  Anywhere that hires good software developers, since if you learned this stack it's presumably not hard to get a job somewhere else? Exooglers have a pretty easy time getting hired.
jasonkester 6y ago
I’m find it amusing that we’ve reached the point where developers can no longer imagine a shop that writes its own software.
- postpawl 6y ago
  The software community has built a lot of extraordinary tools that have been through a lot of battle testing. Pretending those lessons aren’t worth something and thinking you can do it all yourself is a mistake a lot of the time.
  - ratww 6y ago
    If you're taking about foundational dependencies like OpenSSL, Linux, LLVM, or even jQuery and React, sure. Also most stdlibs and DBs, like GP said he uses, also fall into that. Dependencies in general, like 95% (or more) of the kind we see in modern package managers? No, they're mostly untested liabilities and the majority of them could be rewritten in an afternoon. This whole discussion is a bit strange. GP clearly uses dependencies, just not as much as everyone else today. I don't understand why the fixation with polarizing the discussion into "use lots of dependencies" vs "write everything from scratch".
  - dahfizz 6y ago
    The community had produced 1000x as many tools that are garbage. It can sometimes be hard to tell the difference (if the developer cares to look at all).
  - bigiain 6y ago
    "The software community" also built npm, which then enabled "extraordinary tools" like leftpad.js... I suspect there's a lot to be learned from "those battle-tested lessons", but pretending everybody is learning them is a mistake. Dependancies are inevitable. I'm OK with depending on glibc and _almost_ as OK with depending on openssl. And of course I inevitable rely on gcc/clang/CPU microcode/transistor photolithography... But those examples are a world away from npm pulling in 12+ levels of random dependancies of unknown origin buried so deep it's all but impossible to audit - and the segment of "the software comm8unity" who built that particular house-of-cards and then promotes it blindly to the segment of the software community who obliviously use it to generate code that runs on expensive production platforms in business critical applications just boggles my mind. (And makes me alternately weep and drink heavily - having to support exactly that in production because "velocity" and "moving fast and breaking things" are considered more important that quality or security by both management and clients - both of who will happily point the finger of blame elsewhere when the inevitable happens, in spite of having been repeatedly warned... :sigh: )
- bob1029 6y ago
  I think the problem is mostly cognitive. The codebase should be viewed as the most important investment that a software company could ever hope to possess. Within the codebase, the infrastructure and tooling is by far the most important aspect in terms of productivity and stability of daily work process. If you take the time to position yourself accordingly, you can make the leverage (i.e. software that builds the software) work in virtually any way you'd like for it to. If it doesn't feel like you are cheating at the game, you probably didn't dream big enough on the tooling and process. Jenkins, Docker, Kubernetes, GitHub Actions, et. al. are not the pinnacle of software engineering by a long shot.
  - codebje 6y ago
    A company's codebase is a liability, not an asset - it needs to be maintained, and as you point out, it needs money spent on tooling and infrastructure to be most effective. Unless you happen to be one of the very rare companies that sells source code and not built artefacts, your asset is the built artefact and your code is the expense you take on to get it. Having less code to get the business outcome only makes sense when you see the code as a cost, not a thing of value itself.
    - zepearl 6y ago
      > A company's codebase is a liability, not an asset... > your asset is the built artefact Therefore, summarized, you mean that the sourcecode needed to generate the resulting <app/service/whatever> is a liability, but that the result can be an asset (if it does generate external revenue, or internally lowers costs ,etc..)? I personally never thought about this kind of separation - interesting.
      - codebje 6y ago
        I mean that source code comes with costs, often substantial, but has no direct benefits. It's easy for us as developers to think that source code is valuable - but this leads to problems like never removing code "in case it's needed", or with an in-house dev team developing systems you could get off the shelf. If code is an asset, then it makes a lot more sense to write stuff yourself: you not only get the artefact, you also get the source. If it's a liability, then it makes a lot more sense to let someone else bear the costs of that liability, especially if they have economies of scale, except where you can't get your desired outcome other than writing code. This is of course technically incorrect. It's perhaps more accurate to say that source code requires upkeep and is expensive to maintain. That tends to draw less interest and discussion, because it's "obvious." Except as an industry we're overall pretty lousy at paying the required upkeep on code.
- srtjstjsj 6y ago
  If a company isn't competent enough to even check their dependencies for vulnerabilities, as GP's company is, how could they be competent enough to write and check their own alternative versions?
- onion2k 6y ago
  I think this is simply the recognition that our expectations of what team of developers can do in a given time has surpassed what that team can actually write themselves. We know understand that teams have to lean on open source, or buy libraries, in order to achieve what we expect within a reasonable time. The reason is very obvious - the most expensive part of most projects is the people. Why pay them to write code that you can just download for free? That's a tremendous waste of money.
  - robertlagrant 6y ago
    This is exactly it.
- pdimitar 6y ago
  You should raise that point to all the clueless shareholders who relentlessly pulled even technical control out of the hands of the techies. Most of us just do what we're told and we're in no position to question the "company's priorities" -- nevermind the fact that very often those priorities actually align with the techie's vision.
- adrianN 6y ago
  Let's start a car company by first building an iron smelter? Using available tools is not some kind of crazy idea that software engineers came up with in the last ten years.
pwdisswordfish4 6y ago
Original commenter advocates for writing your own, presumably "from scratch", and mentions high-risk targets. Even if you don't take those for granted, though... Let's assume lower risk than a studio, and you relax the conditions from developed-in-house to maintained-in-house (e.g., a library exists, so you go grab it, and by the power of open source, internally it's now "yours"—a fork that you take full responsibility for and have total control over, just like if you had developed in-house, except you're shortcutting the process by cribbing from code that already exists.) Here's an unrecognized truth: The cost of forking a third-party library and maintaining it in-house solely for your own use is no higher than the cost of relying on the third-party's unforked version. Depending on specifics, it can actually be lower. Note that this is a truth; the only real variable is whether it's acknowledged to be true or not. Anyone who disputes it has their thumb on the scale in one way or another, consciously or unconsciously.
- jefftk 6y ago
  You're really claiming this is a universal truth? Do you think it applies to OpenSSL? Chromium?
  - ntauthority 6y ago
    For cryptography one should just be able to rely on their OS' library, and depending on a full browser with high amounts of code churn, no compatibility for implementation code and a large dependency graph of its own is not really seen as a good thing in this context at all.
    - jefftk 6y ago
      Let's be more specific: do you think Brave would be better off if they hard forked Chromium?
  - Godel_unicode 6y ago
    Chromium ships with Windows and is maintained by Microsoft. Use the OS crypto library.
cs02rm0 6y ago
Even without turnover, I've no idea how you're supposed to compete with the quality of top open source software. Maybe no one finds the bugs in your software, but they're definitely there.
- bob1029 6y ago
  We don't try to compete with the quality of top open source software. Our stack fundamentally consists of: C# 8.0 / .NET Core 3.x / AspNetCore / Blazor / SQLite Of these, SQLite is arguably the most stellar example of what open source software can provide to the world. Everything else in our stack consists of in-house primitives built upon these foundational components.
  - Godel_unicode 6y ago
    It's funny to me the number of developers who have effectively forgotten that Microsoft exists, and that it's possible to have your entire stack be provided by one company who directly sells it's software for profit.
  - steverb 6y ago
    That's really interesting. My team's stack is the same except we use Azure SQl server instead of SQLite. I'd love to understand why you chose that. Feel free to hit my up at the address in my profile if you don't want to talk here.
    - baud147258 6y ago
      Perhaps the parent's situation ("software that runs within very secure financial networks" cf https://news.ycombinator.com/item?id=24747781 https://news.ycombinator.com/item?id=24747781) prevents them to rely on an external service?
      - bob1029 6y ago
        We cannot rely on anything outside the client's secure network. There are a few exceptional items that are allowed to talk to the internet, but our system's data persistence layer is not one of them. Effectively, our client's operations cannot rely on cloud services and all of the related last mile connectivity into their infrastructure. If AWS/Azure/et.al. go down, many of our customers are still able to continue operating without difficulty.
brixon 6y ago
A lot of time when you are doing high critical environments you tend to be less cutting edge and rely more on old proven technologies that is boring, but dependable.

alibarber 6y ago

It depends on the context. Yeah it'd be lovely to have your system connected to the internet - but no, our clients wouldn't give us money if you do that, and we need money. So, maybe yes in this case, start writing some quality, well thought out maintainable libraries (that can include audited third party code), and just bill it. In my case, the cost to the client of a team of devs working on that was less than the cost to them of the risk of a film leaking... [Edit] - But what I have found through experience is that the code that was written under these constraints seemed to be better, more secure and robust, than without them. YMMV.

jrumbut 6y ago

I assume if you have the money to be that thorough you have the money to offer some inducements to stick around. Plus if all you know is this custom stack, where are you gonna go?

Godel_unicode 6y ago
Anywhere that hires good software developers, since if you learned this stack it's presumably not hard to get a job somewhere else? Exooglers have a pretty easy time getting hired.

jasonkester 6y ago

I’m find it amusing that we’ve reached the point where developers can no longer imagine a shop that writes its own software.

postpawl 6y ago
The software community has built a lot of extraordinary tools that have been through a lot of battle testing. Pretending those lessons aren’t worth something and thinking you can do it all yourself is a mistake a lot of the time.
- ratww 6y ago
  If you're taking about foundational dependencies like OpenSSL, Linux, LLVM, or even jQuery and React, sure. Also most stdlibs and DBs, like GP said he uses, also fall into that. Dependencies in general, like 95% (or more) of the kind we see in modern package managers? No, they're mostly untested liabilities and the majority of them could be rewritten in an afternoon. This whole discussion is a bit strange. GP clearly uses dependencies, just not as much as everyone else today. I don't understand why the fixation with polarizing the discussion into "use lots of dependencies" vs "write everything from scratch".
- dahfizz 6y ago
  The community had produced 1000x as many tools that are garbage. It can sometimes be hard to tell the difference (if the developer cares to look at all).
- bigiain 6y ago
  "The software community" also built npm, which then enabled "extraordinary tools" like leftpad.js... I suspect there's a lot to be learned from "those battle-tested lessons", but pretending everybody is learning them is a mistake. Dependancies are inevitable. I'm OK with depending on glibc and _almost_ as OK with depending on openssl. And of course I inevitable rely on gcc/clang/CPU microcode/transistor photolithography... But those examples are a world away from npm pulling in 12+ levels of random dependancies of unknown origin buried so deep it's all but impossible to audit - and the segment of "the software comm8unity" who built that particular house-of-cards and then promotes it blindly to the segment of the software community who obliviously use it to generate code that runs on expensive production platforms in business critical applications just boggles my mind. (And makes me alternately weep and drink heavily - having to support exactly that in production because "velocity" and "moving fast and breaking things" are considered more important that quality or security by both management and clients - both of who will happily point the finger of blame elsewhere when the inevitable happens, in spite of having been repeatedly warned... :sigh: )
bob1029 6y ago
I think the problem is mostly cognitive. The codebase should be viewed as the most important investment that a software company could ever hope to possess. Within the codebase, the infrastructure and tooling is by far the most important aspect in terms of productivity and stability of daily work process. If you take the time to position yourself accordingly, you can make the leverage (i.e. software that builds the software) work in virtually any way you'd like for it to. If it doesn't feel like you are cheating at the game, you probably didn't dream big enough on the tooling and process. Jenkins, Docker, Kubernetes, GitHub Actions, et. al. are not the pinnacle of software engineering by a long shot.
- codebje 6y ago
  A company's codebase is a liability, not an asset - it needs to be maintained, and as you point out, it needs money spent on tooling and infrastructure to be most effective. Unless you happen to be one of the very rare companies that sells source code and not built artefacts, your asset is the built artefact and your code is the expense you take on to get it. Having less code to get the business outcome only makes sense when you see the code as a cost, not a thing of value itself.
  - zepearl 6y ago
    > A company's codebase is a liability, not an asset... > your asset is the built artefact Therefore, summarized, you mean that the sourcecode needed to generate the resulting <app/service/whatever> is a liability, but that the result can be an asset (if it does generate external revenue, or internally lowers costs ,etc..)? I personally never thought about this kind of separation - interesting.
    - codebje 6y ago
      I mean that source code comes with costs, often substantial, but has no direct benefits. It's easy for us as developers to think that source code is valuable - but this leads to problems like never removing code "in case it's needed", or with an in-house dev team developing systems you could get off the shelf. If code is an asset, then it makes a lot more sense to write stuff yourself: you not only get the artefact, you also get the source. If it's a liability, then it makes a lot more sense to let someone else bear the costs of that liability, especially if they have economies of scale, except where you can't get your desired outcome other than writing code. This is of course technically incorrect. It's perhaps more accurate to say that source code requires upkeep and is expensive to maintain. That tends to draw less interest and discussion, because it's "obvious." Except as an industry we're overall pretty lousy at paying the required upkeep on code.
srtjstjsj 6y ago
If a company isn't competent enough to even check their dependencies for vulnerabilities, as GP's company is, how could they be competent enough to write and check their own alternative versions?
onion2k 6y ago
I think this is simply the recognition that our expectations of what team of developers can do in a given time has surpassed what that team can actually write themselves. We know understand that teams have to lean on open source, or buy libraries, in order to achieve what we expect within a reasonable time. The reason is very obvious - the most expensive part of most projects is the people. Why pay them to write code that you can just download for free? That's a tremendous waste of money.
- robertlagrant 6y ago
  This is exactly it.
pdimitar 6y ago
You should raise that point to all the clueless shareholders who relentlessly pulled even technical control out of the hands of the techies. Most of us just do what we're told and we're in no position to question the "company's priorities" -- nevermind the fact that very often those priorities actually align with the techie's vision.
adrianN 6y ago
Let's start a car company by first building an iron smelter? Using available tools is not some kind of crazy idea that software engineers came up with in the last ten years.

pwdisswordfish4 6y ago

Original commenter advocates for writing your own, presumably "from scratch", and mentions high-risk targets. Even if you don't take those for granted, though... Let's assume lower risk than a studio, and you relax the conditions from developed-in-house to maintained-in-house (e.g., a library exists, so you go grab it, and by the power of open source, internally it's now "yours"—a fork that you take full responsibility for and have total control over, just like if you had developed in-house, except you're shortcutting the process by cribbing from code that already exists.) Here's an unrecognized truth: The cost of forking a third-party library and maintaining it in-house solely for your own use is no higher than the cost of relying on the third-party's unforked version. Depending on specifics, it can actually be lower. Note that this is a truth; the only real variable is whether it's acknowledged to be true or not. Anyone who disputes it has their thumb on the scale in one way or another, consciously or unconsciously.

jefftk 6y ago
You're really claiming this is a universal truth? Do you think it applies to OpenSSL? Chromium?
- ntauthority 6y ago
  For cryptography one should just be able to rely on their OS' library, and depending on a full browser with high amounts of code churn, no compatibility for implementation code and a large dependency graph of its own is not really seen as a good thing in this context at all.
  - jefftk 6y ago
    Let's be more specific: do you think Brave would be better off if they hard forked Chromium?
- Godel_unicode 6y ago
  Chromium ships with Windows and is maintained by Microsoft. Use the OS crypto library.

cs02rm0 6y ago

Even without turnover, I've no idea how you're supposed to compete with the quality of top open source software. Maybe no one finds the bugs in your software, but they're definitely there.

bob1029 6y ago
We don't try to compete with the quality of top open source software. Our stack fundamentally consists of: C# 8.0 / .NET Core 3.x / AspNetCore / Blazor / SQLite Of these, SQLite is arguably the most stellar example of what open source software can provide to the world. Everything else in our stack consists of in-house primitives built upon these foundational components.
- Godel_unicode 6y ago
  It's funny to me the number of developers who have effectively forgotten that Microsoft exists, and that it's possible to have your entire stack be provided by one company who directly sells it's software for profit.
- steverb 6y ago
  That's really interesting. My team's stack is the same except we use Azure SQl server instead of SQLite. I'd love to understand why you chose that. Feel free to hit my up at the address in my profile if you don't want to talk here.
  - baud147258 6y ago
    Perhaps the parent's situation ("software that runs within very secure financial networks" cf https://news.ycombinator.com/item?id=24747781 https://news.ycombinator.com/item?id=24747781) prevents them to rely on an external service?
    - bob1029 6y ago
      We cannot rely on anything outside the client's secure network. There are a few exceptional items that are allowed to talk to the internet, but our system's data persistence layer is not one of them. Effectively, our client's operations cannot rely on cloud services and all of the related last mile connectivity into their infrastructure. If AWS/Azure/et.al. go down, many of our customers are still able to continue operating without difficulty.

brixon 6y ago

A lot of time when you are doing high critical environments you tend to be less cutting edge and rely more on old proven technologies that is boring, but dependable.