HACKER Q&A
📣 barking_biscuit

How much software is too much for one team?


I work in a group of two teams at the moment that owns something like 80+ bits of software. This includes 11 or so APIs/products that sit right at the core of the business domain, as our teams together own the core business domain and are supposed to provide internal APIs for other teams to build products on top of. Internally we have many platform teams which offer PaaS stuff, but seem to only use a fraction of it, rather there's a tonne of one-off tooling we've built for our services that also some other teams leverage too despite that we're not one of these PaaS teams, nor is it anything to related to the domain we actually own. For a while I thought it made sense, but as I look around the organisation I'm starting to feel like it makes less and less sense as I realise the only engineer that actually knows much about it is the one that built it all. From time to time I see that we've also built our own chatbot framework too and every time I see it I wonder "why do we have to own this thing and maintain it???". Lately I feel really burdened by all this extra stuff that's hanging around and starting to push back on it and ask questions. I did some digging around our company to try and get a sense of what's normal and found some data indicating our team owns a ratio of 5 bits of software for every 1 engineer which is much higher than most other teams.

What's really bothering me lately is when I push back on this and start to question "how do other teams handle this?", "what's preventing us from using the PaaS offerings?", "do you think this is a reasonable amount of software for a single engineer to be across?", I get responses from the person who built all this extra stuff that are very defensive in nature and quite dismissive of how the extra cognitive load makes me feel. What worries me is they have been with the company 8 years and given they built most of the stuff have very strong mental models of it and hence are very comfortable/competent in this little kingdom of code and in stark contrast roughly 2/3 of the team has been there a year or less and I see a lot of people struggling to be across that much software and showing fatigue from the cognitive load placed on us, and I don't think they're able to properly empathize with how it's actually affecting the team.

Anyone else been in this situation? Any advice?


  👤 ericalexander0 Accepted Answer ✓
There is no magical ratio. Brooks's law applies, but it's detriment can be acceptable, if it's not impacting customer value.

Don't focus on the input variables (ie we have n engineers). Focus on the output variables. What are the SLA/Os for each service? If they're being met, then it's unlikely anything should change. Missed SLAs should trigger changes (see scaled agile framework).