5 ms·

> No engineer wants to be on the hook for a bunch of things cobbled together like this in production. How are you going to hire talent? How do you test the thin

> No engineer wants to be on the hook for a bunch of things cobbled together like this in production. How are you going to hire talent? How do you test the thing? Debug it? Logs? Analytics? The point was that most of these things become less relevant when the surface area of the codebase gets smaller. Individual utilities are generally easier to understand, test and debug as separate units, logging is already baked into the system (syslog, anyone?), and why would you need analytics?

lolinder 3y ago
So what do you do when your customers say "this is great, when are you adding screen sharing"? Where do voice calls fit into this architecture, do we just add another UNIX util and stream the bits over SSH? Furthermore, debugging may be "easier" insofar as the units are discrete (though any good modular architecture will have the same advantage), but what do you do when you find a bug? If you're running a business, you can't be in a place where you're just submitting it upstream and telling your customers that every single bug is waiting for a vendor fix. So now you have to take ownership of maintaining and repairing each and every UNIX utility you use. In what world is that easier than having 500k lines of Go in a consistent company style? Joel Spolsky's advice is pertinent [0]: > If it’s a core business function — do it yourself, no matter what. https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
- revelio 3y ago
  You can't fix bugs in Slack so that seems hardly comparable. Screen sharing and video calls can be handled by other apps like Zoom, Google Meet etc.
  - lolinder 3y ago
    I'm not talking about self-hosting suc, I'm arguing that all those extra lines of code in Mattermost (and presumably Slack) aren't doing nothing—a lot of them are a necessity if you're selling a software product.
    - norir 3y ago
      Sure, there is a lot of code that is doing something, but is it doing the right thing correctly and efficiently? It's likely that a > 500k sloc project is filled with low quality and inefficient code. I'm pretty sure this is a natural law. The only way to limit this is by placing quality and efficiency among the highest virtues, which is essentially anti-capitalist.
TheIronMark 3y ago
As a development exercise, this is neat, but its extreme focus on software dev makes it just that: an exercise. Slack incorporates all of the extra stuff suc ignores because it's a service; you're paying for someone else to handle the integrations for access control and authz and such. Homegrown solutions require varying levels of support. Something like Slack is predictable and that makes it attractive, from a business perspective.

lolinder 3y ago

So what do you do when your customers say "this is great, when are you adding screen sharing"? Where do voice calls fit into this architecture, do we just add another UNIX util and stream the bits over SSH? Furthermore, debugging may be "easier" insofar as the units are discrete (though any good modular architecture will have the same advantage), but what do you do when you find a bug? If you're running a business, you can't be in a place where you're just submitting it upstream and telling your customers that every single bug is waiting for a vendor fix. So now you have to take ownership of maintaining and repairing each and every UNIX utility you use. In what world is that easier than having 500k lines of Go in a consistent company style? Joel Spolsky's advice is pertinent [0]: > If it’s a core business function — do it yourself, no matter what. https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

revelio 3y ago
You can't fix bugs in Slack so that seems hardly comparable. Screen sharing and video calls can be handled by other apps like Zoom, Google Meet etc.
- lolinder 3y ago
  I'm not talking about self-hosting suc, I'm arguing that all those extra lines of code in Mattermost (and presumably Slack) aren't doing nothing—a lot of them are a necessity if you're selling a software product.
  - norir 3y ago
    Sure, there is a lot of code that is doing something, but is it doing the right thing correctly and efficiently? It's likely that a > 500k sloc project is filled with low quality and inefficient code. I'm pretty sure this is a natural law. The only way to limit this is by placing quality and efficiency among the highest virtues, which is essentially anti-capitalist.

TheIronMark 3y ago

As a development exercise, this is neat, but its extreme focus on software dev makes it just that: an exercise. Slack incorporates all of the extra stuff suc ignores because it's a service; you're paying for someone else to handle the integrations for access control and authz and such. Homegrown solutions require varying levels of support. Something like Slack is predictable and that makes it attractive, from a business perspective.