←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: 0.273s | source
Show context
dakiol ◴[14 Oct 24 21:23 UTC] No.41842172[source]▶
I once worked for a company that required from each engineer in the team to do what they called “firefighting” during working hours (so not exactly on-call). So for one week, I was triaging bug tickets and trying to resolve them. These bugs belonged to the area my team was part of, so it affected the same product but a vast amount of micro services, most of which I didn’t know much about (besides how to use their APIs). It didn’t make much sense to me. So you have Joe punching code like there’s no tomorrow and introducing bugs because features must go live asap. And then it’s me the one fixing stuff. So unproductive. I always advocated for a slower pace of feature delivery (so more testing and less bugs on production) but everyone was like “are you from the 80s or something? We gotta move fast man!”
replies(5): >>41842203 #>>41842403 #>>41842705 #>>41845436 #>>41846116 #
1. onion2k ◴[15 Oct 24 06:11 UTC] No.41845436[source]▶
This sort of thing is introduced when the number of bugs in production, especially bugs that aren't user-facing or a danger to data (eg 'just' an unhandled exception or a weird log entry), gets to a peak and someone decides it's important enough to actually do something about it. Those things are always such a low priority that they're rarely dealt with any other way.

In my experience whenever that happens someone always finds an "oh @#$&" case where a bug is actually far more serious than everyone thought.

It is an approach that's less productive than slowing down and delivering quality, but it's also completely inevitable once a team/company grows to a sufficient size.