
Ask HN: How do you flag features in your codebase? - Mernit
I am an engineering manager at a 30 person startup in New York. Recently, we found a last minute bug in our code as we were preparing a deployment for our biggest client. This happened on a Friday after everyone left, so I begun to message each engineer individually (9 staffed on this project) to track down the source of the bug and figure out a solution. Luckily, it only took an hour to figure out where the bug was occurring and which engineer had originally developed the code for it.
This ordeal made me think about a better way to manage dependancies in code - specifically, some system to keep track of WHO has special knowledge about a specific feature in our codebase.<p>At any given moment, I have a general idea of who is working on what, but I don&#x27;t know who is working on what parts, i.e. Bob and Charlie might both be working on a billing system together, but I don&#x27;t know which one of them is working on the DB models and which one is working on the Stripe API.<p>Git Blame is a theoretical solution to this problem, but it is only useful once I have isolated a bug to a specific point in the code. Ideally, I would like a Git Blame-like system at the repo level so that I (and my non-technical colleagues) can quickly track down which engineers are responsible for specific features in my codebase.<p>How do people manage this process in their organizations?
======
cetico
I ran the production systems for various Google products and this was an
interesting challenge there because there were many engineers and many changes
done every day.

One imperfect but helpful technique is to use release notes for your
application.

Ask the team to write good commits when changing code, and aggregate all code
changes done to the application into a page that describes what went in that
release. GitHub releases do that for you automatically. When a release is
pushed that breaks something, it's easier to scan the release notes and find
who changed what.

Another technique is to use explicit feature flags to protect all code
changes. Then use a dashboard that shows recent changes to feature flags –
again this helps tracking down the culprit.

------
bobblywobbles
I don't know of any service that does this, but you could write a process that
could analyze every line in a given repo. Weight for each line of code would
have to be balanced against the number of lines previously written by that
developer, as well as the date of the commit (more-recent commits weigh more)
and perhaps the TFS work item associated with the changeset, and other details
of the TFS work item/bug.

IMO, it seems a lot more work than the value can provide - a simple answer
from one of the devs suffices, it's what the process has been for me.

