Assume you are a developer working through a feature enhancement. The enhancement requires changes in several areas of the codebase, some of which you are not too familiar with in terms of convention and best practice on how variables should be named, errors should be logged, functions should be used, and what classes do what. However, despite this lack of domain knowledge, you are under the gun by the product team to release the enhancement, and the development team with the subject matter expertise is tied up on a critical bug issue. You know the change is small, and you make it, but you leave behind the following:
//TODO: Cleanup the error handling on this code
You leave this behind with the intention of a developer with the right subject matter expertise picking this up in the future and actually making the code look the way it should and handle the errors in the appropriate way. Will that ever happen? Probably not. The right developers will never be notified and the //TODO will likely never come to their attention, unless they happen to scan over it. The issue isn’t big enough to warrant adding it to the project board or issue tracker, and you definitely don’t want the project managers and product owners catchng wind of it since they might take it as an impedence to progress. This is where proper //TODO organization and tagging can come in handy.
Tagging and Filtering
Qwoka offers the ability to tag //TODOs with custom tags that can then be filtered on. For example, if the above //TODO existed in the area of the codebase concerned with “shopping cart” logic, the developer could tag it like so:
//TODO: Cleanup the error handling on this code //@tags: cart
With the above //TODO added, it would then show up in Qwoka like so:
Then, with the filtering and dashboard capabilities of Qwoka, a developer that has their main dashboard configured to filter for “cart” tags will see the //TODO pop up and they can include it in their next change. As the //TODO ages, they will see it start to float to the top of the dashboard so that it wont become stale.
The issue did not pose an impedence for the actual product, but did pose a potential hazard down the line from a technical perspective. It wasn’t urgent and did not require a ticket, however without organized //TODOs, the action item would have probably been lost forever.