6 ms·

Most of the comments here are along the lines of: this is old tech! But this isn’t really about the tech, it as much a productivity hack that allows people to

Most of the comments here are along the lines of: this is old tech! But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors

ljm 6y ago
Somewhere along the way Mythical Man Month was turned from a cautionary tale into a competition, and it only ever seems to happen once VC gets their mitts on a company. Does it really take a team of 800 engineers to maintain your fancy todo list app, rather than your focussed team of 10 or 20? What are all of those people doing except piling on organisational cruft so the business has no choice but to over-encumber itself with talent? Most of them aren't working on the product, that's for sure.
- jack_riminton 6y ago
  Yeah somewhere along the line people confused success with the amount of money you’ve raised and the number of people you employ. This just incentivises complexity
- notsureaboutpg 6y ago
  At scale, yeah it does take a lot of people to do this. It has nothing to do with the type of app and everything to do with how business works. At scale you have huge enterprise customers with complex setups and they want to integrate your fancy todo list app into their setup and will pay you tons to do it. Your fancy todo list app suddenly needs to have all sorts of security certifications, needs to guarantee some type of uptime, needs to be able to integrate with all sorts of systems and other products (some of which none of your current engineers will have experience with). A new device will be released (think Apple Watch) and you're leaving money on the table if you don't hire some engineers to put your fancy todo list app on that platform along with the 5 or 6 others it's already maintained on. At scale, 1 in a million type bugs/problems come up every day and you need more engineers to deal with them. At scale, you are generating and producing (and thus need to be collecting and analyzing) an amazing amount of data, which should be used to better your product, learn about your customers and try to grow your business into providing other products and services your customers want / need. All that data collection, storage, and analysis requires more and more engineers.
- swlkr 6y ago
  These companies might hire people as an edge against any future competition. Talented engineers are tied up doing menial tasks but getting paid $300k/year, cheaper than having to compete?
  - ymolodtsov 6y ago
    There's only a handful companies out there who might be doing that, namely Google, Facebook and a few others. No other company is at the scale to meaningfully affect the market.
ivanhoe 6y ago
It's a productivity hack for companies that have more backend devs that strongly prefer ruby to javascript, like a presume basecamp team is... AFAIK this doesn't apply to the average web dev teams nowadays, most of whom never even used ruby before...
- jack_riminton 6y ago
  Yes funnily enough a Rails feature will only help those who code with Rails
  - jack_riminton 6y ago
    Correction: this doesn't actually seem to be Rails specific at all
  - ivanhoe 6y ago
    There's a plenty of people using RoR, but feeling equally productive in JS, and they'll benefit significantly less than backend developers who were forced into using it, but never really liked it.
- ksec 6y ago
  LiveWire on Laravel PHP LiveView on Phoniex Blazor on .Net
  - ivanhoe 6y ago
    So, what's your argument exactly? In every language there's a number of back-end devs who simply don't like using javascript, they want to do everything in a single language, and this is the tool for them. And that's great. I'm just saying that I don't think there's a significant number of them, that's all. Most of young people seem to be enjoying the modern javascript nowadays, and I see zero benefit for them in any of those tools. And the popularity of the tools like LiweWire kinda shows it, as I've heard a lot of Laravel people talking about it, but I personally don't know a single one who actually switched to using it for work in the end... maybe it takes more time, we'll see...

ljm 6y ago

Somewhere along the way Mythical Man Month was turned from a cautionary tale into a competition, and it only ever seems to happen once VC gets their mitts on a company. Does it really take a team of 800 engineers to maintain your fancy todo list app, rather than your focussed team of 10 or 20? What are all of those people doing except piling on organisational cruft so the business has no choice but to over-encumber itself with talent? Most of them aren't working on the product, that's for sure.

jack_riminton 6y ago
Yeah somewhere along the line people confused success with the amount of money you’ve raised and the number of people you employ. This just incentivises complexity
notsureaboutpg 6y ago
At scale, yeah it does take a lot of people to do this. It has nothing to do with the type of app and everything to do with how business works. At scale you have huge enterprise customers with complex setups and they want to integrate your fancy todo list app into their setup and will pay you tons to do it. Your fancy todo list app suddenly needs to have all sorts of security certifications, needs to guarantee some type of uptime, needs to be able to integrate with all sorts of systems and other products (some of which none of your current engineers will have experience with). A new device will be released (think Apple Watch) and you're leaving money on the table if you don't hire some engineers to put your fancy todo list app on that platform along with the 5 or 6 others it's already maintained on. At scale, 1 in a million type bugs/problems come up every day and you need more engineers to deal with them. At scale, you are generating and producing (and thus need to be collecting and analyzing) an amazing amount of data, which should be used to better your product, learn about your customers and try to grow your business into providing other products and services your customers want / need. All that data collection, storage, and analysis requires more and more engineers.
swlkr 6y ago
These companies might hire people as an edge against any future competition. Talented engineers are tied up doing menial tasks but getting paid $300k/year, cheaper than having to compete?
- ymolodtsov 6y ago
  There's only a handful companies out there who might be doing that, namely Google, Facebook and a few others. No other company is at the scale to meaningfully affect the market.

ivanhoe 6y ago

It's a productivity hack for companies that have more backend devs that strongly prefer ruby to javascript, like a presume basecamp team is... AFAIK this doesn't apply to the average web dev teams nowadays, most of whom never even used ruby before...

jack_riminton 6y ago
Yes funnily enough a Rails feature will only help those who code with Rails
- jack_riminton 6y ago
  Correction: this doesn't actually seem to be Rails specific at all
- ivanhoe 6y ago
  There's a plenty of people using RoR, but feeling equally productive in JS, and they'll benefit significantly less than backend developers who were forced into using it, but never really liked it.
ksec 6y ago
LiveWire on Laravel PHP LiveView on Phoniex Blazor on .Net
- ivanhoe 6y ago
  So, what's your argument exactly? In every language there's a number of back-end devs who simply don't like using javascript, they want to do everything in a single language, and this is the tool for them. And that's great. I'm just saying that I don't think there's a significant number of them, that's all. Most of young people seem to be enjoying the modern javascript nowadays, and I see zero benefit for them in any of those tools. And the popularity of the tools like LiweWire kinda shows it, as I've heard a lot of Laravel people talking about it, but I personally don't know a single one who actually switched to using it for work in the end... maybe it takes more time, we'll see...