6 ms·

I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here. I

by hliyan 6d ago

I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here. I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities. I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.

hankbond 6d ago
yes but also people-churn/attrition was likely lower too. it can really hurt your career to stay in most organizations more than 2 years because very few places devote any meaningful resources to growing from within. if you want better opportunities and more comp it often requires moving companies.
hermitShell 6d ago
If you've not read Fred Brooks MMM, give it a shot. It seems like you're implying that teams of 60-80 developers should be expected to outperform teams of 12. This is simply not true. The most important feature of source code as a language is that it allows precise mindshare among close knit teams. It doesn't guarantee it, but it makes it possible for people to talk about the product at a level that is otherwise very difficult. A convenient side-effect of the source code is that it instructs the machine what to do. But instructing the machine was never the bottleneck, the essential difficulty of software development is in understanding what are the correct instructions to achieve some objective, not typing them out. The problem is that communication doesn't scale at all. Having just 3 developers with good alignment about mental models, best practices, and design direction is hard enough, and if you found the right three people at the right time with the right ideas, you could generate billions of dollars of value. Large monolithic teams on the order of 80 are a product of people in control not understanding how software development works, and how to make it work well.
anthonypasq 6d ago
the average developer back then was much better. 50% of engineers in the average IT department produce zero or negative value. I worked at one of the largest financial institutions in the world and had coworkers that literally committed zero code for months.
- sph 6d ago
  I don't think it's because of the 'average developer', but because system's like OP's were designed by experienced engineers, while the modern toolchain is written by "senior developers" with 3 years of experience. They have a lot of energy to pull all-nighters reinventing yet another wheel, and not the wisdom to avoid doing that, or to do it in a sensible way. In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem. tl;dr: modern software is built by 'work hard, not smart' kinda types.
- bluefirebrand 6d ago
  > coworkers that literally committed zero code for months That's awesome I would much prefer to have coworkers that literally commit zero code than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
  - rwmj 6d ago
    > than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code We've managed to emulate this behaviour in silicon now.
kerblang 6d ago
Yes the modern toolchain is super-massive. There is no pushback. Remember when deployment was trivial? My expectation is that the toolchain will expand by another order of magnitude because LLM's, not just because of what they can produce, but because we are lowering the ceiling with LLM assistance when it comes to just understanding the toolchain. That creates a vacuum that people can fill up with more stuff. The "insanity" that makes people do this is hard to explain. It's certainly irrational and seemingly unconscious.
robotnikman 6d ago
Man I wish I was born 20 years earlier so I could be working in the golden age of developers like this (and also buy a home at a decent price)
- michaelrpeskin 6d ago
  I resemble that remark. The trouble is that I'm now too old and if I ever lose my job, I'll never find another one. No one hiring in tech wants the greybeards.
  - daveguy 5d ago
    Getting the kids to insist they be paid what their contributions are worth would raise the boat for all developers. Of course that would take some sort of big bad union, which the oligarch vc asshats really don't like.
- hliyan 6d ago
  I feel for you. We didn't know how good we had it. Wooed by multiple companies right out of university, good salary, comfortable, fulfilling work (some nights though), fast path to car and home ownership and long term financial security. Few rules/restrictions more perks compared to other professions. We were spoiled. Perhaps this is why the current crop of tech leaders are behaving like spoiled brats.
cpeterso 6d ago
Joel Spolsky's "Fire And Motion" blog post (2002) describes the challenge of tech churn well: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ > Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

by hliyan 6d ago

hankbond 6d ago

yes but also people-churn/attrition was likely lower too. it can really hurt your career to stay in most organizations more than 2 years because very few places devote any meaningful resources to growing from within. if you want better opportunities and more comp it often requires moving companies.

hermitShell 6d ago

If you've not read Fred Brooks MMM, give it a shot. It seems like you're implying that teams of 60-80 developers should be expected to outperform teams of 12. This is simply not true. The most important feature of source code as a language is that it allows precise mindshare among close knit teams. It doesn't guarantee it, but it makes it possible for people to talk about the product at a level that is otherwise very difficult. A convenient side-effect of the source code is that it instructs the machine what to do. But instructing the machine was never the bottleneck, the essential difficulty of software development is in understanding what are the correct instructions to achieve some objective, not typing them out. The problem is that communication doesn't scale at all. Having just 3 developers with good alignment about mental models, best practices, and design direction is hard enough, and if you found the right three people at the right time with the right ideas, you could generate billions of dollars of value. Large monolithic teams on the order of 80 are a product of people in control not understanding how software development works, and how to make it work well.

anthonypasq 6d ago

the average developer back then was much better. 50% of engineers in the average IT department produce zero or negative value. I worked at one of the largest financial institutions in the world and had coworkers that literally committed zero code for months.

sph 6d ago
I don't think it's because of the 'average developer', but because system's like OP's were designed by experienced engineers, while the modern toolchain is written by "senior developers" with 3 years of experience. They have a lot of energy to pull all-nighters reinventing yet another wheel, and not the wisdom to avoid doing that, or to do it in a sensible way. In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem. tl;dr: modern software is built by 'work hard, not smart' kinda types.
bluefirebrand 6d ago
> coworkers that literally committed zero code for months That's awesome I would much prefer to have coworkers that literally commit zero code than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
- rwmj 6d ago
  > than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code We've managed to emulate this behaviour in silicon now.

kerblang 6d ago

Yes the modern toolchain is super-massive. There is no pushback. Remember when deployment was trivial? My expectation is that the toolchain will expand by another order of magnitude because LLM's, not just because of what they can produce, but because we are lowering the ceiling with LLM assistance when it comes to just understanding the toolchain. That creates a vacuum that people can fill up with more stuff. The "insanity" that makes people do this is hard to explain. It's certainly irrational and seemingly unconscious.

robotnikman 6d ago

Man I wish I was born 20 years earlier so I could be working in the golden age of developers like this (and also buy a home at a decent price)

michaelrpeskin 6d ago
I resemble that remark. The trouble is that I'm now too old and if I ever lose my job, I'll never find another one. No one hiring in tech wants the greybeards.
- daveguy 5d ago
  Getting the kids to insist they be paid what their contributions are worth would raise the boat for all developers. Of course that would take some sort of big bad union, which the oligarch vc asshats really don't like.
hliyan 6d ago
I feel for you. We didn't know how good we had it. Wooed by multiple companies right out of university, good salary, comfortable, fulfilling work (some nights though), fast path to car and home ownership and long term financial security. Few rules/restrictions more perks compared to other professions. We were spoiled. Perhaps this is why the current crop of tech leaders are behaving like spoiled brats.

cpeterso 6d ago

Joel Spolsky's "Fire And Motion" blog post (2002) describes the challenge of tech churn well: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ > Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.