3 ms·

The problem I see is that Jira encourages "management by looking at Jira" - effectively Jira becomes a second source of truth that is unconnected and unconstrai

The problem I see is that Jira encourages "management by looking at Jira" - effectively Jira becomes a second source of truth that is unconnected and unconstrained by the actual truth (the code). Jira acquires state that has to be carefully maintained as a separate operation by the developers to keep Jira's state in sync with the actual state of the project. Since most of the organisation are looking at Jira, the effective source of truth becomes Jira's current state, and the developers end up running to try and keep the actual project in sync with Jira. Or they become disconnected and Jira's state becomes completely independent of the actual project state (tickets being marked as "done" that aren't complete, or sometimes even started, because it doesn't matter because everyone is looking at Jira and not at the code). I would love to see Jira state somehow derived from the state of the codebase. Tickets get marked complete when they are actually complete in the code, with tests and documentation and everything, because the ticket state is derived from the code state.

justahuman74 3y ago
You can write glue for whatever hosts your repository to make api calls to Jira. Say you have some code that needs some changes but at a later time, you can put a comment above it (or really anywhere) // JIRA: MYPROJ-123 When the glue sees that comment disappear from the codebase, it can mark the ticket as done.
- marcus_holmes 3y ago
  Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around. The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.
  - Tainnor 3y ago
    What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.
    - superice 3y ago
      Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.
      - marcus_holmes 3y ago
        yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting... edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.
      - Tainnor 3y ago
        Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code. The other problem is that you still need to track when all the tests for the feature have been written.
- usrbinbash 3y ago
  The code is the model. The project management system is the view. The model shouldn't have to change to accomodate the view.
fijiaarone 3y ago
Code is not a source of truth, it is an attempt at partial realization of an incomplete understanding of a bunch of contradictory assumptions about what’s true at a particular point in time.
- blowski 3y ago
  It's a source of truth about what code has been written.
  - deleted 3y ago
    [deleted]
Tainnor 3y ago
The code itself doesn't even contain much of the information relevant to coders, you'd have to also look at the git repo, its history, its commits, etc. The code, or the repo, however are in most cases not the source of truth for a business roadmap, prioritisation discussions, estimation, customer feedback, bug reports, and so on. It's a myopic view to only look at the code without any of its context and conclude that it's "the" source of truth. Also, I don't know about you, but most places I've worked haven't struggled with keeping the code and JIRA in sync.
- marcus_holmes 3y ago
  I've noticed it particularly with outsource teams where the communication is difficult. The team update tickets with what management expect, not what code has actually been written.
plumarr 3y ago
I have used Jira at several place, and every time that it worked fine Jira was the source of thruth for the project. There was no shadow tracking beside it. So everybody updated it happily and used it. You can't do that based of the code because the code is limited to its content. How do you track everything that isn't in it ? (requirements, relation with other teams, delivery to customer, customer tickets,...)

justahuman74 3y ago

You can write glue for whatever hosts your repository to make api calls to Jira. Say you have some code that needs some changes but at a later time, you can put a comment above it (or really anywhere) // JIRA: MYPROJ-123 When the glue sees that comment disappear from the codebase, it can mark the ticket as done.

marcus_holmes 3y ago
Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around. The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.
- Tainnor 3y ago
  What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.
  - superice 3y ago
    Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.
    - marcus_holmes 3y ago
      yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting... edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.
    - Tainnor 3y ago
      Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code. The other problem is that you still need to track when all the tests for the feature have been written.
usrbinbash 3y ago
The code is the model. The project management system is the view. The model shouldn't have to change to accomodate the view.

fijiaarone 3y ago

Code is not a source of truth, it is an attempt at partial realization of an incomplete understanding of a bunch of contradictory assumptions about what’s true at a particular point in time.

blowski 3y ago
It's a source of truth about what code has been written.
- deleted 3y ago
  [deleted]

Tainnor 3y ago

The code itself doesn't even contain much of the information relevant to coders, you'd have to also look at the git repo, its history, its commits, etc. The code, or the repo, however are in most cases not the source of truth for a business roadmap, prioritisation discussions, estimation, customer feedback, bug reports, and so on. It's a myopic view to only look at the code without any of its context and conclude that it's "the" source of truth. Also, I don't know about you, but most places I've worked haven't struggled with keeping the code and JIRA in sync.

marcus_holmes 3y ago
I've noticed it particularly with outsource teams where the communication is difficult. The team update tickets with what management expect, not what code has actually been written.

plumarr 3y ago

I have used Jira at several place, and every time that it worked fine Jira was the source of thruth for the project. There was no shadow tracking beside it. So everybody updated it happily and used it. You can't do that based of the code because the code is limited to its content. How do you track everything that isn't in it ? (requirements, relation with other teams, delivery to customer, customer tickets,...)