Live data from Hacker News

There's no such thing as a small software team anymore

jacob.gold

71–80 of 183 posts

Re: There's no such thing as a small software team anymore

#71
Is this satire? Changing your easy to maintain monolith architecture to a microservice architecture to enable parallel agent development, really? That's got to be some of the worst advice I'd heard in a long time.

You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict.

And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?

Re: There's no such thing as a small software team anymore

#72

Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily. Only the seniors who know their systems are keeping the lights on today by keeping bs commits out. Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.

You can already see a practical example of this in microsoft's issues with Azure. Too many services, too little understanding, everyone left who knows what is going on. There was an interesting article here a little while ago by one of the architects something like "how azure set a trillion dollars on fire" or something like that.

Re: There's no such thing as a small software team anymore

#73
post #66

Earlier quoted context omitted.

currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?

who is it reducing qol for? I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?

Massive price increases for any electronics that contains RAM, SSDs, etc. has hurt everyone. The GPU supply crunch has hurt a smaller swath but hardly zero.

Re: There's no such thing as a small software team anymore

#74
post #45

Earlier quoted context omitted.

Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system compared to a monolith. Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. I would generally not recommend adding all this overhead unless ab…

> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.

Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.

Re: There's no such thing as a small software team anymore

#75
post #70

Earlier quoted context omitted.

> plan for a world where it's always summer The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.

It's a pun on AI winter - if there's not going to be a winter, then it's always summer. But things won't be static. It is in fact normal for new technologies to be adopted, and for there to be no cycle where the technology just disappears. There was no Internet winter or railroad winter, not in the same way there was an AI winter where AI just went away. Those technologies had valuation bubbles but the technologies t…

My counterpoint is that "the internet" is quite recent, and has had many iterations - we've basically abandoned gopher, mostly irc, etc. Even "the web" as we know it is arguably entering a winter we can't yet foresee the duration of.

I 100% agree that "AI" is not going anywhere as long as humans are here (I wouldn't be building a company in the space otherwise).

I'm challenging this specific absolute certainty that "a swarm of agents building code like ants" will be living in eternal summer. This paradigm might be completely different just 6 months from now, from all we know!

Re: There's no such thing as a small software team anymore

#76
i agree with this.. but also think it could stress a couple things more:

- satisfying the needs of parallel agentic development is wholly aligned with the optimal DevSecOps CI/CS/CD WhateverTerm models out there. And that's rad, bc a lot of orgs have a reference frame to map to.

- microservices, monoliths, monorepos, mammoths, whatever.. The code and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo)

- strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that

Re: There's no such thing as a small software team anymore

#77

Earlier quoted context omitted.

Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice. They still make up some whole product that presumably does something as a…

Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time. With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making…

You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.

Re: There's no such thing as a small software team anymore

#78

Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product. Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been repl…

> Hundreds of bots modifying thousands of microservices may sound good on the surface

It really does not, honestly.

Re: There's no such thing as a small software team anymore

#79

Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product. Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been repl…

>Hundreds of bots modifying thousands of microservices

That is way too close to monkeys on typewriters for comfort.

Re: There's no such thing as a small software team anymore

#80
post #43
post #3

I'm a 1 person dev team who wrote frontend code that outperforms React. Is was successful because I didn't use any sort of LLM assistance.

That's pretty impressive. I always like bespoke web utilities tailored for specific dev purposes. What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?

Same as op, I rewrote away from react my Dropbox alternative (https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this:

  export default function component(render) {
      const $dom = xxxx
      render($dom);
  }
example: https://github.com/mickael-kerjean/filestash/blob/master/pub... the only library in there is rxjs to manipulate events in a functional fashion with no imperative code and everything is composed from those simple component functions. The wasm is used mostly as an interface for plugins to both run apps to display various file types like RAW, PSD, TIFF, CDR, .... as those tend to have better support in C than other languages, and on the server side to have a safe environment to execute plugin code.
Post reply on HN