4 ms·

I have a better idea: instead of adding tasks to a random line in a random file deep in the source code, add them to your ticketing system and make them part of

by sedatk 5y ago

I have a better idea: instead of adding tasks to a random line in a random file deep in the source code, add them to your ticketing system and make them part of your development cycle. They'll get triaged based on their business value instead of an arbitrary developer's discretion, making better use of resources.

mlyle 5y ago
For awhile we did both-- we had some glue we'd written which turned TODO comments into issues. Then for things that were truly related to somewhere deep in the source code, they could be marked there for anyone seeing the code and in the issue tracker. The biggest issue was, the magic we'd come up with to prevent spurious closing/opening of these issues was insufficient for formatting and reorganization, and it resulted in unnecessary churn in the issue tracker and for some comments on these issues to be lost. But done better I think it could still be valuable.
- a-dub 5y ago
  i've considered writing tooling like this. maybe not tying to ticketing systems, but instead like some sort of scorekeeping system for tech debt. maybe add some fun incentives like "if your patch removes more tech debt than it creates in terms of specially formatted TODOs, then you get to jump the CI line" or somesuch.
  - Jolter 5y ago
    Check our Sonarqube. It has gating functionality that you can enable for TODOs and I’m pretty sure it can tally up number of todos as part of its tech debt calculator.
nivertech 5y ago
I want the opposite - tickets-as-code as part of the git repo. Something like SIT[1]. Fossil has it, but today's standard DVCS is git. There are 2 trends here: 1. Everything-as-a-code stored in the git repo in a text format close to the actual source code. If you store documention-as-a-code, diagrams-as-a-code, IaaC, tests-as-a-code, loadtesting-as-a-code, etc. - then why not issues/tickets as a code also? 2. Reduce number of tools/services/mechanisms you use in order to eliminate impedance mismatch, simplify workflows, and remove barriers to collaboration. For example if you standardize on Github, then you can use Guthub Issues, Projects, Packages, Actions, Codespaces, etc. And most developers are already having Github a/c. [1] https://github.com/sit-fyi/sit https://github.com/sit-fyi/sit
- thow_away_soon 5y ago
  This reminded me of toodles[0], a nice project you can use to visualize TODO comments as issues. I didn't have the chance to try it, but I'm looking forward it for my next project [0] https://github.com/aviaviavi/toodles https://github.com/aviaviavi/toodles
- crdrost 5y ago
  So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹ Postmodernism gets a bad rap from modernists as being anti-Truth, and you can see this somewhat in how a Subversion diehard might view Git, “okay but what is the real truth of the code?” Git had this from kernel development, the real truth is that there are about a million different Linuxes out there due to combinatorial explosion, this one is kernel 4.15 with patches X, and Y applied, that one is 4.15 with X and Z applied...” It's not a philosophical choice but a practical reality for Linux. And so too, branch names in Git generally have process associated with them, they have to get their meaning by sociopolitical agreement among the developers and their tooling. This conspicuous reference to tooling highlights something really important. Git’s postmodernism is constantly clashing with the modernism of Prod. We expect our websites to have one canonical authoritative Truth, at least until we start really committing to postmodernism making A/B testing etc. the norm. You see this last point particularly in the context of Gitlab and GitHub doing CI/CD tasks.² And indeed now the general wisdom is to do trunk-based development, in other words try to ditch postmodernism at this level, thinking that way is too hard when we've got such a modernist reality in front of us, let us instead bound our postmodernism in modernism-plus-feature-toggles or or so. Anyway, the reason I'm ranting about all of this to you is that the same modernism/postmodernism tension is present for issue tracking. Yes, logically an issue should be closed by a commit that fixes the issue. This means that an issue can be closed in production and still open in some feature branch, say. Makes perfect sense. Especially this plays well with one piece of advice I am always giving people, which is that the size of your repository, monorepo vs mini-repo, should be at the level that it makes sense to time-travel on.³ Except: we might like a very modernist view on our issues. We might want them to have a single known status, some person worked on it and finished it and now it is done. We want this issue to be in a Kanban board, say. Does a new issue get merged into all of the release candidates? Those sorts of questions. So again, trunk based development may be necessary to mitigate the mismatch. [1] Postmodernism means a lot of different things to a lot of people. For a quick perspective to help this comment make sense, I take postmodernism as saying that there are blind-sages-and-the-elephant problems for any sufficiently interesting topic: there are multiple perspectives which each give you a partial truth, and only by seeing something from many perspectives do you get a well-rounded education on it. Furthermore, if people are saying “they're actually is only one correct perspective, one sage is Correct above all others, and it is This One” then that is best interpreted not as a genuine criticism of other ideas but as a power grab of sorts—the problem is sociopolitical and not technical. [2] How do you configure those tasks? “With a file in the repository.” Oh, you mean a CI/CD branch that has one particular name and sets the rules for all branches, per modernist requirement? “No, like in the root of each branch’s folder structure. Like the prod and develop branches will both say “if my branch name is ‘prod’ then deploy me to production,” but this will only trigger for the one branch.” And if I push up a new branch called “hotfix” that says “deploy me to production if my name is ‘prod’ or ‘hotfix’?” Um, er, ah. This is a hard problem that both companies had to invent some sort of external-to-repo tooling for, because they both failed to understand the most basic thing about Git! You want a different take, look to Gerrit. ACLs are in the refs/meta/config branch—ah! [3] That is, if you have microservices and it makes no sense to roll back one microservice 30 days without rolling back another, which will probably be using some new functionality that was added to the first—then you should version both together even if you build/release separately. (Git lets you get subtree hashes for this pretty easily.)
com2kid 5y ago
The ticketing system at work is complicated enough that I tend to avoid using it. Also I find that tickets get lost, sometimes for almost a year, before bubbling up in backlog grooming again.
hnbad 5y ago
The official GitHub extension for VS Code actually provides a way to turn TODO comments into GitHub issues with minimal manual interaction. This can help avoiding the context switch of opening your ticketing system rather than just staying in the editor.

by sedatk 5y ago

mlyle 5y ago

For awhile we did both-- we had some glue we'd written which turned TODO comments into issues. Then for things that were truly related to somewhere deep in the source code, they could be marked there for anyone seeing the code and in the issue tracker. The biggest issue was, the magic we'd come up with to prevent spurious closing/opening of these issues was insufficient for formatting and reorganization, and it resulted in unnecessary churn in the issue tracker and for some comments on these issues to be lost. But done better I think it could still be valuable.

a-dub 5y ago
i've considered writing tooling like this. maybe not tying to ticketing systems, but instead like some sort of scorekeeping system for tech debt. maybe add some fun incentives like "if your patch removes more tech debt than it creates in terms of specially formatted TODOs, then you get to jump the CI line" or somesuch.
- Jolter 5y ago
  Check our Sonarqube. It has gating functionality that you can enable for TODOs and I’m pretty sure it can tally up number of todos as part of its tech debt calculator.

nivertech 5y ago

I want the opposite - tickets-as-code as part of the git repo. Something like SIT[1]. Fossil has it, but today's standard DVCS is git. There are 2 trends here: 1. Everything-as-a-code stored in the git repo in a text format close to the actual source code. If you store documention-as-a-code, diagrams-as-a-code, IaaC, tests-as-a-code, loadtesting-as-a-code, etc. - then why not issues/tickets as a code also? 2. Reduce number of tools/services/mechanisms you use in order to eliminate impedance mismatch, simplify workflows, and remove barriers to collaboration. For example if you standardize on Github, then you can use Guthub Issues, Projects, Packages, Actions, Codespaces, etc. And most developers are already having Github a/c. [1] https://github.com/sit-fyi/sit https://github.com/sit-fyi/sit

thow_away_soon 5y ago
This reminded me of toodles[0], a nice project you can use to visualize TODO comments as issues. I didn't have the chance to try it, but I'm looking forward it for my next project [0] https://github.com/aviaviavi/toodles https://github.com/aviaviavi/toodles
crdrost 5y ago
So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹ Postmodernism gets a bad rap from modernists as being anti-Truth, and you can see this somewhat in how a Subversion diehard might view Git, “okay but what is the real truth of the code?” Git had this from kernel development, the real truth is that there are about a million different Linuxes out there due to combinatorial explosion, this one is kernel 4.15 with patches X, and Y applied, that one is 4.15 with X and Z applied...” It's not a philosophical choice but a practical reality for Linux. And so too, branch names in Git generally have process associated with them, they have to get their meaning by sociopolitical agreement among the developers and their tooling. This conspicuous reference to tooling highlights something really important. Git’s postmodernism is constantly clashing with the modernism of Prod. We expect our websites to have one canonical authoritative Truth, at least until we start really committing to postmodernism making A/B testing etc. the norm. You see this last point particularly in the context of Gitlab and GitHub doing CI/CD tasks.² And indeed now the general wisdom is to do trunk-based development, in other words try to ditch postmodernism at this level, thinking that way is too hard when we've got such a modernist reality in front of us, let us instead bound our postmodernism in modernism-plus-feature-toggles or or so. Anyway, the reason I'm ranting about all of this to you is that the same modernism/postmodernism tension is present for issue tracking. Yes, logically an issue should be closed by a commit that fixes the issue. This means that an issue can be closed in production and still open in some feature branch, say. Makes perfect sense. Especially this plays well with one piece of advice I am always giving people, which is that the size of your repository, monorepo vs mini-repo, should be at the level that it makes sense to time-travel on.³ Except: we might like a very modernist view on our issues. We might want them to have a single known status, some person worked on it and finished it and now it is done. We want this issue to be in a Kanban board, say. Does a new issue get merged into all of the release candidates? Those sorts of questions. So again, trunk based development may be necessary to mitigate the mismatch. [1] Postmodernism means a lot of different things to a lot of people. For a quick perspective to help this comment make sense, I take postmodernism as saying that there are blind-sages-and-the-elephant problems for any sufficiently interesting topic: there are multiple perspectives which each give you a partial truth, and only by seeing something from many perspectives do you get a well-rounded education on it. Furthermore, if people are saying “they're actually is only one correct perspective, one sage is Correct above all others, and it is This One” then that is best interpreted not as a genuine criticism of other ideas but as a power grab of sorts—the problem is sociopolitical and not technical. [2] How do you configure those tasks? “With a file in the repository.” Oh, you mean a CI/CD branch that has one particular name and sets the rules for all branches, per modernist requirement? “No, like in the root of each branch’s folder structure. Like the prod and develop branches will both say “if my branch name is ‘prod’ then deploy me to production,” but this will only trigger for the one branch.” And if I push up a new branch called “hotfix” that says “deploy me to production if my name is ‘prod’ or ‘hotfix’?” Um, er, ah. This is a hard problem that both companies had to invent some sort of external-to-repo tooling for, because they both failed to understand the most basic thing about Git! You want a different take, look to Gerrit. ACLs are in the refs/meta/config branch—ah! [3] That is, if you have microservices and it makes no sense to roll back one microservice 30 days without rolling back another, which will probably be using some new functionality that was added to the first—then you should version both together even if you build/release separately. (Git lets you get subtree hashes for this pretty easily.)

com2kid 5y ago

The ticketing system at work is complicated enough that I tend to avoid using it. Also I find that tickets get lost, sometimes for almost a year, before bubbling up in backlog grooming again.

hnbad 5y ago

The official GitHub extension for VS Code actually provides a way to turn TODO comments into GitHub issues with minimal manual interaction. This can help avoiding the context switch of opening your ticketing system rather than just staying in the editor.