21–29 of 29 posts
Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?
If there weren't "clear owners," who was approving code changes for merge? Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?
Needing to list an "executive sponsor" (an individual, not a role or a team) for each and every item in a service catalogue seems like mindless bureaucracy. Meanwhile, having "custom properties" attached to each repo feels very much like administering JIRA, and schema-less YAML blobs that pervade the GitOps world. Is it just me, or isn't the glaringly obvious solution to this an actual database and API, rather than j…
Source: my workflow once they required various TPS forms to be completed before you were allowed to create a new repository.
If there weren't "clear owners," who was approving code changes for merge? Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?
A previous employer hit the problem where there were a ton of legacy features that didn't have clear owners and so it wasn't clear where to route bug reports. Their solution was to build a catalog of every feature and then assign EVERY one of them to an existing team. Teams might end up responsible for features that they had never seen before and had no knowledge of... but that was fine, because every other team was…
It’s like the bystander effect but for code, lol. Just pick someone and give them the task.
A large tech company decided to stop having subteams responsible for particular features or areas of the code for one of their products. The result was developers having to spend inordinate amounts of time researching highly complex spec documents and reference manuals on a daily basis for even the smallest of fixes. It drove moral into the ground and developers started a mass exodus to other teams or tech companies.
After some changes of management for the team, the policy had to be reversed to stem the bleeding. Turns out that developers don't like permanently being in unfamiliar territory.
If there weren't "clear owners," who was approving code changes for merge? Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?
If there weren't "clear owners," who was approving code changes for merge? Every other major arm of Microsoft has been tasked with burdensome controls over tracking any and all production changes to source code, but Github was operating without a useful system and record of ownership for nearly 80% of its repos (11000/14000)?
I think they mean "clear owners" as in "responsible individuals," not that the repos literally lacked people with merge approval rights.
Earlier quoted context omitted.
It’s like the bystander effect but for code, lol. Just pick someone and give them the task.
On complex codebases, I've seen this strategy absolutely decimate team moral. A large tech company decided to stop having subteams responsible for particular features or areas of the code for one of their products. The result was developers having to spend inordinate amounts of time researching highly complex spec documents and reference manuals on a daily basis for even the smallest of fixes. It drove moral into the…