←back to thread

Splitting engineering teams into defense and offense

(www.greptile.com)
210 points dakshgupta | 1 comments | 14 Oct 24 20:07 UTC | HN request time: 0s | source
Show context
Attummm ◴[15 Oct 24 12:56 UTC] No.41848077[source]▶
When you get to that stage, software engineering has failed fundamentally.

This is akin to having a boat that isn't seaworthy, so the suggestion is to have a rowing team and a bucket team. One rows, and the other scoops the water out. While missing the actual issue at hand. Instead, focus on creating a better boat. In this case, that would mean investing in testing: unit tests, integration tests, and QA tests.

Have staff engineers guide the teams and make their KPI reducing incidents. Increase the quality and reduce the bugs, and there will be fewer outages and issues.

replies(4): >>41848735 #>>41849757 #>>41849885 #>>41852908 #
1. intelVISA ◴[15 Oct 24 20:45 UTC] No.41852908[source]▶
Yep, software is about cohesion. Having one side beloved by product and blessed with 'the offense' racing ahead to create extra work for the other is not the play.

Even when they rotate - who wants to clock in to wade through a fresh swamp they've never seen? Don't make the swamp: if you're moving too slow shipping things without sinking half the ship each PR then raise your budget to better engineers - they exist.

This premise is like advocating for tech debt loan sharks; I really hope TFA was ironic. Sure, it makes sense from a business perspective as a last gasp to sneakily sell off your failed company but you would never blog "hey here at LLM-4-YOU, Inc. we're sinking".