> I promised a better way... a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets.
I'm mystified... everywhere I've ever worked used design documents to some extent -- not for simple features, but more for things that are truly "complicated systems" with nuances.
Are there really places that attempt to do project design solely with tickets? I almost can't believe it.
(Although in terms of effort estimation, breaking the design doc down afterwards into tickets, and then estimating those individually, is a very useful exercise -- a design doc describes the outcome, the tickets describe how to get there, which is what you're really estimating.)
Its a recent trend to skip the documentation and have a sparsely documented JIRA in the belief it encourages agile development. I just groan when i see it
there is also the "let's define everything by user stories" way of doing things (as if having a bunch of stories in whatever agile tool is better than a proper functional spec / design spec)
It seems like most organizations that use JIRA start off with good intentions, but it eventually devolves into a huge mess that users dread. Maybe it's because the system tries to do too much or, more likely, it's a user problem and orgs demand more and more features. Whatever the cause, it's leading to a death by 1000 cuts.
For me, JIRA is addressing a fundamentally difficult problem: how to separate work on a monolith between several people. At some point the separation into tickets, tasks, requirements or whatever one wants to call them is necessary.
For me, JIRA is addressing a fundamentally difficult problem: how to separate work on a monolith between several people. At some point the separation into tickets, tasks, requirements or whatever one wants to call them is necessary.
> And so JIRA ticketing subtly but powerfully tends to push developers to work on one ticket at a time, instead, which is often both less efficient and more prone to drastic late-in-the-game failure.
Technical debt is measured in net present value.
As a QA engineer myself, it is more valuable to explicitly account for when and why a given software change is made then it is to rush things out, because when a later change inevitably breaks an older one, the engineer can immediately know when and why it happened, and what to fix.
Relying solely on design documents means that if something goes wrong in a sufficiently complex system, it can take a very long time to isolate and fix the issue. (no, TDD does not alleviate this)
For projects where there's possibly only a dev or two and the project/client, we had success with producteev. It's much less complicated than e.g. JIRA.
If you set up rules for tags and priorities you can manage delivery quite well with it.
> I stress that it’s not specifically JIRA itself which is guilty of this. All of the above is implicit in the notion of reducing software architecture and development to a set of “tickets.” JIRA’s great sin is only that of being the most successful and widespread ticketing system. The notion of specifying a software project with a set of tickets is itself the enemy.
Every large scale software system needs a ticket system if some kind. You might separate the backlog from the bug reports, or omit one part, but you'll have something.
You can't find the reason for a change otherwise, you can't find all the related changes for the feature, you can't catalog incoming bugs and answer whether the last bug report must be tackled or has already been fixed and so on.
This is why - like it or not - there always is an issue management system. It's on a server somewhere, or in an excel sheet, or emails, or on a piece of paper. But it's there.
The usual criticism of Jira is that it's heavyweight compared to e.g GitHubs issue tracker, or whatever post-it moving system is the latest fad.
A fair criticism of Jira is that it makes it too easy for management to encode and expand the formal rules for e.g task workflows, and that these rules invariably end up being too rigid.
An organization should have the least invasive workflow it can, but it should encode and enforce the workflow.
In the end, just like you always have an issue management system, you also have a change workflow. Either it's encoded formally using an issue/PR system or it's ad-hoc via chat and email (which scales very well up to around 2 developers but shows it's weaknesses already at around 3)
That's the main failure mode I've seen. An over-engineered and role-limited workflow in which the real-life state of the project is considered invalid or nobody is authorized to express it.
YMMV but one method I like to mitigate the issue the article talks about is keeping documentation in source control, and requiring a change to documentation (or explanation why there should be no documentation change) in association with the resolution of a JIRA ticket.
The author clearly doesn't have the experience in agile development necessary to be commenting on this. As a software engineer turned scrum master, I can say that my company is a well oiled machine using JIRA and agile methodologies perfectly well. My engineers don't have these complaints. Clearly he's doing it wrong.
Hackers, Very Well written article, we have been facing this pain point and we went on to create a wonderful system which handles everything for a project in a simple intutive way. I have shared the screenshot here for the hackers. Lot of positive feedback, looking forward to hear your sincere comments and take it forward.
19 comments
[ 2.5 ms ] story [ 49.1 ms ] threadI'm mystified... everywhere I've ever worked used design documents to some extent -- not for simple features, but more for things that are truly "complicated systems" with nuances.
Are there really places that attempt to do project design solely with tickets? I almost can't believe it.
(Although in terms of effort estimation, breaking the design doc down afterwards into tickets, and then estimating those individually, is a very useful exercise -- a design doc describes the outcome, the tickets describe how to get there, which is what you're really estimating.)
Technical debt is measured in net present value.
As a QA engineer myself, it is more valuable to explicitly account for when and why a given software change is made then it is to rush things out, because when a later change inevitably breaks an older one, the engineer can immediately know when and why it happened, and what to fix.
Relying solely on design documents means that if something goes wrong in a sufficiently complex system, it can take a very long time to isolate and fix the issue. (no, TDD does not alleviate this)
For projects where there's possibly only a dev or two and the project/client, we had success with producteev. It's much less complicated than e.g. JIRA.
If you set up rules for tags and priorities you can manage delivery quite well with it.
Highest priority is reserved for blockers.
Sample of our tags: affects customer, bug, feature, change, production, technical debt
> I stress that it’s not specifically JIRA itself which is guilty of this. All of the above is implicit in the notion of reducing software architecture and development to a set of “tickets.” JIRA’s great sin is only that of being the most successful and widespread ticketing system. The notion of specifying a software project with a set of tickets is itself the enemy.
Hope that saves ppl from this terrible clickbait
You can't find the reason for a change otherwise, you can't find all the related changes for the feature, you can't catalog incoming bugs and answer whether the last bug report must be tackled or has already been fixed and so on.
This is why - like it or not - there always is an issue management system. It's on a server somewhere, or in an excel sheet, or emails, or on a piece of paper. But it's there.
The usual criticism of Jira is that it's heavyweight compared to e.g GitHubs issue tracker, or whatever post-it moving system is the latest fad.
A fair criticism of Jira is that it makes it too easy for management to encode and expand the formal rules for e.g task workflows, and that these rules invariably end up being too rigid.
An organization should have the least invasive workflow it can, but it should encode and enforce the workflow.
In the end, just like you always have an issue management system, you also have a change workflow. Either it's encoded formally using an issue/PR system or it's ad-hoc via chat and email (which scales very well up to around 2 developers but shows it's weaknesses already at around 3)
https://pbs.twimg.com/media/CzeajADUUAE87oa.jpg