←back to thread

Splitting engineering teams into defense and offense

(www.greptile.com)
210 points dakshgupta | 3 comments | 14 Oct 24 20:07 UTC | HN request time: 0s | source
Show context
glenjamin ◴[15 Oct 24 11:43 UTC] No.41847498[source]▶
Having a proportion of the team act as triage for issues / alerts / questions / requests is a generally good pattern that I think is pretty common - especially when aligned with an on-call rotation. I've done it a few times by having a single person in a team of 6 or 7 do it. If you're having to devote 50% of your 4-person team to this sort of work, that suggests your ratios are a bit off imo.

The thing I found most surprising about this article was this phrasing:

> We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.

This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration and I think you'd benefit from adopting a much more continuous integration and deployment process.

replies(5): >>41847622 #>>41847713 #>>41847719 #>>41849997 #>>41850708 #
The_Colonel ◴[15 Oct 24 12:11 UTC] No.41847713[source]▶
> This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration

I don't think it suggests how the time block translates into PRs. It could very well be a series of PRs.

In any case, the nature of the product / features / refactorings usually dictates the minimum size of a PR.

replies(1): >>41847761 #
marcinzm ◴[15 Oct 24 12:16 UTC] No.41847761[source]▶
> In any case, the nature of the product / features / refactorings usually dictates the minimum size of a PR.

Why not split the big tickets into smaller tickets which are delivered individually? There's cases where you literally can't but in my experience those are the minority or at least should be assuming a decently designed system.

replies(2): >>41847880 #>>41849976 #
The_Colonel ◴[15 Oct 24 12:31 UTC] No.41847880[source]▶
> Why not split the big tickets into smaller tickets which are delivered individually?

Because it is already the smallest increment you can make. Or because splitting it further would add a lot of overhead.

> There's cases where you literally can't but in my experience those are the minority

I think in this sentence, there's a hidden assumption that most projects look like your project(s). That's likely false.

replies(1): >>41848008 #
1. marcinzm ◴[15 Oct 24 12:48 UTC] No.41848008[source]▶
> I think in this sentence, there's a hidden assumption that most projects look like your project(s). That's likely false.

You left out the part of that quote where I explained my assumption very clearly: A decently designed system.

In my experience if you cannot split tasks into <1 week the vast majority of the time then your code has massive land mines in it. The design may be too inter-connected, too many assumptions baked too deeply, not enough tests, or various other issues. You should address those landmines before you step on them rather than perpetually trying to walk around them. Then splitting projects down becomes much much easier.

replies(1): >>41848274 #
2. The_Colonel ◴[15 Oct 24 13:19 UTC] No.41848274[source]▶
> You left out the part of that quote where I explained my assumption very clearly: A decently designed system.

That's one possible reason. Sometimes software is designed badly from the ground up, sometimes it accumulates a lot of accidental complexity over years or decades. Solving that problem is usually out of your control in those cases, and only sometimes there's a business driver to fix it.

But there are many other cases. You have software with millions of lines of code, decades of commit history. Even if the design is reasonable, there will be a significant amount of both accidental and essential complexity - from certain size/age you simply won't find any pristine, perfectly clean project. Implementing a relatively simple feature might mean you will need to learn the interacting features you've never dealt with so far, study documentation, talk to people you've never met (no one has a complete understanding either). Your acceptance testing suite runs for 10 hours on a cluster of machines, and you might need several iterations to get them right. You have projects where the trade-off between velocity and tolerance for risk is different from yours, and the processes designed around it are more strict and formal than you're used to.

replies(1): >>41850508 #
3. skydhash ◴[15 Oct 24 16:49 UTC] No.41850508[source]▶
And also you have to backport all the changes that have been made on the main branch. Especially for upgrading or stack switching tasks.