[HN Gopher] Everything's a bug (or an issue)
___________________________________________________________________
Everything's a bug (or an issue)
Author : dboreham
Score : 52 points
Date : 2025-05-19 03:46 UTC (3 days ago)
(HTM) web link (www.bozemanpass.com)
(TXT) w3m dump (www.bozemanpass.com)
| teeray wrote:
| > Error establishing a database connection
|
| Simply poetry
| codydkdc wrote:
| If I'm understanding correctly GitHub Projects solve your
| concerns with using GitHub Issues
| 0atman wrote:
| I believe the principles the article author is looking for are
| core to Pivotal Tracker. I've often tried to persuade teams to
| use Tracker, but everyone sure loves the whiteboard metaphor!
| queezey wrote:
| Unfortunately, Pivotal Tracker was decommissioned on April 30,
| 2025. It's dead and gone.
|
| Related HackerNews discussion:
| https://news.ycombinator.com/item?id=41591622
| vinnymac wrote:
| I used to use PT for years. Nowadays I use Linear instead for
| project management and love it.
|
| In true pivotal tracker spirit their mobile apps are
| terrible, but perhaps that's for the best.
| cratermoon wrote:
| I like that the author distinguishes priority and severity,
| something rarely appreciated in my experience. Many teams
| conflate them, spending time working on severe bugs simply
| because they are severe, when there are important and essential
| fixes in the queue for the next release.
| jes5199 wrote:
| "badly broken but doesn't matter"?
| sixtram wrote:
| A totally broken function that a single person uses once a
| month to save five minutes isn't nearly as valuable as a
| well-designed feature that 5,000 users rely on daily to save
| just one minute each session.
| djeastm wrote:
| In my experience it depends on who the single person is in
| the pecking order.
| Joker_vD wrote:
| Well, yes. The point is, just because a toaster has
| rusted through because you've left it on your apartment's
| balcony for 6 years (because you don't make toasts) --
| which is pretty severe -- it doesn't make it your top
| priority to fix it. Until, of course, you mother-in-law
| arrives and throws a spectacular tantrum about the lack
| of fresh toasts, or something.
| dylan604 wrote:
| That's the thing though, there's always going to be the
| mother-in-law tantrum that pops up to totally wreck
| anyone's priorities. Best laid plans will always be
| tossed out the window because some favored user/client
| contacts someone high enough that everything you were
| doing is now put on hold to address something that was
| already evaluated as a lower priority task be all stake
| holders involved.
|
| It makes priority lists a joke to me. I've been in
| meetings where every single new action item became the
| highest priority, where at the end of the meeting
| everyone is confused on what the priorities are. It's bad
| management, and it is utterly demoralizing.
| scotty79 wrote:
| With popularity of myriad of development methodologies there was
| DDD, Debug Driven Development. You start a project by filing the
| first bug: "The app shouldn't be blank."
| bdhcuidbebe wrote:
| How would you debug that, tho?
| Joker_vD wrote:
| There seems to be the source code missing. No worries, you
| just start writing it. After this is done with, you end up
| with an empty project/app/web-page/executable/whatever that,
| however, builds, launches, and runs. Second bug: "the
| application is just a blank page/screen that doesn't really
| do anything". And so on.
| SoftTalker wrote:
| Loved Bugzilla back in the '00s. Used it just as the author
| described: everything was a bug. New features, enhancements,
| actual bugs/problems. Worked very well.
|
| I would differ from the author on the need for tight coupling to
| source control. There could be any number of folks who want to
| see what's going on with an item but have no interest in or even
| understanding of the actual related code. It's easy enough to
| include a bug number in commit messages to tie the two together.
| crabbone wrote:
| > It's easy enough to include a bug number in commit messages
| to tie the two together.
|
| No. This is absolutely not enough. Does the commit resolve the
| issue? Does it add a test to the issue? Does it disable the
| buggy feature?
|
| Also, I'm of an opinion that if you are hired to work in
| software development company, you need to learn how to use
| version control. Just suck it up, if you don't like it. No
| excuses. Version control is the protocol for sharing
| information, especially useful because it's understood by the
| "grunts" actually creating the product. If a manger doesn't
| understand this language he or she will be as useless as a
| manager who doesn't speak any natural language his or her team
| speaks.
|
| In general, from the QA perspective, QA wants to know a lot
| more about the connection between the bug and the source code.
| It may ask questions s.a. "What general group of issues is
| affected by the change?" or "Is this a work-in-progress kind of
| change?" or "Does this change affect the performance of the
| system?" or "Is this change known to affect another change,
| perhaps these changes are mutually exclusive?" or "Is this
| change intended for a particular release of the product?". This
| and similar information is necessary for QA to minimize the
| number of useless tests to run, to minimize the number of
| pointless alerts, to have a hope of producing reliable metrics
| that show overall product quality level increase / decrease.
| quietbritishjim wrote:
| > > It's easy enough to include a bug number in commit
| messages to tie the two together.
|
| > No. This is absolutely not enough. Does the commit resolve
| the issue? Does it add a test to the issue? Does it disable
| the buggy feature?
|
| They just said that the bug number was enough to "to tie the
| two together". They didn't claim that was all that the commit
| message can or should say. For example, "added tests for #24"
| (followed by some details) would follow that template.
|
| > Also, I'm of an opinion that if you are hired to work in
| software development company, you need to learn how to use
| version control. Just suck it up, if you don't like it. No
| excuses. Version control is the protocol for sharing
| information, especially useful because it's understood by the
| "grunts" actually creating the product. If a manger doesn't
| understand this language he or she will be as useless as a
| manager who doesn't speak any natural language his or her
| team speaks.
|
| This is ludicrous. The point of version control is to
| understand the way that the _source code_ changes. Managers
| do not need to understand the software at that level of
| granularity, that is our job as software developers. Issue
| trackers are a much better fit for that.
| crabbone wrote:
| > They just said that the bug number was enough to "to tie
| the two together".
|
| What's the other one they are tying together? Presumably
| the first one is the commit...
|
| > This is ludicrous. The point of version control is to
| understand the way that the source code changes.
|
| No it's not. This is why version control exists in programs
| that generally don't deal with code, s.a. Microsoft Word
| for example.
| Joker_vD wrote:
| And the other is the bug, whose number is being include
| in the commit message. So the commit is tied to the bug
| it addresses (whatever "addresses" may mean) by including
| the ID of that bug in the commit message.
|
| Also, just to clarify, you can have several commits that
| refer to the same bug, and also commit message may (and
| likely should) contain some other text in addition to the
| bug number.
| oftenwrong wrote:
| Regarding priorities, a manager from my past used a system that I
| liked: Each person had a set of tickets assigned to them, but
| there was always an unambiguous priority order. At any given
| time, a given worker would work on their highest-priority ticket
| that progress could be made on at that time. If anyone wanted to
| shift that worker to another ticket, then the priorities needed
| to be adjusted, and the worker would be notified (if they didn't
| do it themselves). This helped make it clear what people were
| expected to be working on, and made it easy to see what people
| were currently working on.
| crabbone wrote:
| This article is a lot of ado and pretty shallow understanding of
| how various departments in software company utilize bug trackers
| to promote some changes the author added to Gitea project.
|
| In not so many words: Gitea bug tracking ability is poor. The
| author improved it a little bit, but still not enough for it to
| be good.
| arzmir wrote:
| While we've only used it for a small size greenfield project with
| 5-6 developers, we have been very happy with the user experience
| of Linear [1]. It ties reasonably well into GitHub and have
| plenty other useful integrations. Notion among others. I imagine
| this would cover many of the author's needs, and I think it also
| support GitHub as IDP.
|
| [1] https://linear.app
| stevekemp wrote:
| I've been forced to use linear a fair bit recently and I have
| to say it's a mess of client-side javascript that often gets
| itself into a weird state.
|
| For example open five tabs, each pointing to a new issue. Then
| clicking on an issue in the current cycle will just show a
| blank page.
|
| Or when accepting an issue from triage you might find it
| defaults to "subscribe to updates", randomly. Or you might find
| you're the owner of a new story for no reason.
|
| The number of times I have to force-reload the website to "fix"
| things is uncountable. And the whole forced-workflow is
| unpleasant compared to how I prefer to work. I mean it's better
| than Jira, in most ways, but .. sometimes I wish to go back to
| server-rendered stuff even if it is Atlassian-speed, where it
| felt like your server literally was in Australia the amount of
| time page-fetches took to complete.
| duxup wrote:
| I'm always interested in hearing how folks manage these kinds of
| things hoping to find some clarity, but by the end of reading I'm
| always thinking "this is all just an organizational preference /
| horse trading one issue for another".
|
| Still, good read none the less.
| robertpateii wrote:
| > to see what an individual is working on, what they'll be
| working on next, *and what they done recently.*
|
| This last bit is useful, but tricky to get reports on in a single
| assignee system. Say it's the end of the week and I want to show
| off myself or my team. The system would need to track assignee at
| resolution or at re-assignment, or let me filter all of one
| user's activities down.
|
| Does any single-assignee system handle this well? I've always had
| to manually take note of bug IDs mentioned in standups to achieve
| a good list of who did what when only using one assignee at a
| time.
| joshstrange wrote:
| I'm sorry but that system (bug council) sure seems like it's
| being viewed through rose-colored glasses and/or I don't know how
| well it could work today in a remote environment. Even when I was
| in an office, if you have a meeting with more than 3 people at
| least 1 person is not paying attention.
|
| Bug council seems like a huge waste of time (I manage 9
| developers but sub-groups are working on completely different
| projects (which is why it's broken into 3 teams). Bringing in
| another team to hear about bugs from a different team almost
| guarantees zoning out even if there is valuable info being
| shared.
|
| Also, I don't see how this process works with general project
| management. Are there no sprints? How do you track what people
| are working on and if it's too much? How do you track that people
| are completing tasks in a reasonable time? A single-assignee
| system doesn't solve that. Powerful queries don't solve that.
|
| I've used bugzilla before, it's the same as any other ticketing
| system at the end of the day and no ticketing system can solve
| project management for you. The things this author is focusing on
| confuse me and those have never been problems I've run into with
| managing projects/teams.
___________________________________________________________________
(page generated 2025-05-22 23:01 UTC)