16 ms·

I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed)

by tootie 6y ago

I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. And developers are expensive as hell. And I've also never worked anywhere that had a better option than JIRA.

TheFunkyMonk 6y ago
I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.
- SideburnsOfDoom 6y ago
  You are an assembly line robot.
  - kiaulen 6y ago
    This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.
    - SideburnsOfDoom 6y ago
      > Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".
      - turbinerneiter 6y ago
        Exactly. What's going on is commits and merges. They live in GitLab. There is also tickets in GitLab, which all developers are happy to use. There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites! But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is another platform with a complex and slow ui, and our docs formerly markdown are now in some proprietary confluence RTF, which can export to word and PDF - with no custom styling.
        novok 6y ago
        I haven't used gitlab's wiki specifically, but the reason why you would use something like confluence is because you get a wiki with a wysiwyg editor, so less technical people can use it without having to learn markdown and there is less friction to making docs. It's not specific to confluence. Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.
        turbinerneiter 6y ago
        I'd argue that Markdown is easier to learn than confluence wysiwyg, and also more useful in the long run. Especially as there are many GUI Markdown editors with buttons and preview windows, that give you best of both worlds.
        deleted 6y ago
        [deleted]
        deleted 6y ago
        [deleted]
        pm90 6y ago
        The constraint for the org I work in is that GitHub has a per user license fee that makes it difficult to justify getting a license for everyone in the org since we have a lot of non developer staff. But everyone has access to confluence/JIRA. Does Gitlab also have similar license restrictions?
  - TheFunkyMonk 6y ago
    Do you prefer to... not have all the details in front of you for a task you're about to work on?
    - stefanmichael 6y ago
      Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you. As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company, etc. edit: anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone
      - reificator 6y ago
        > anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone I would, but that's a detail that a senior dev like yourself should be able to figure out without people just providing it for you.
      - majewsky 6y ago
        I agree with your assessment, having experienced a gradual shift from junior to senior myself. As for why the downvotes, hypothesis 1: People might misconstrue your position as "senior ICs are supposed to design the system entirely on their own". I understand you as "management provides the direction and some design constraints, seniors fill in the details, juniors just implement specifications from the seniors", which matches my experience. Hypothesis 2: Maybe it's a culture thing? I'm guessing from your user name that you're from Europe, and I'm from Germany. Maybe the downvoters are literally coming from a different place? (Don't know how it would be different over there though.)
      - codenesium 6y ago
        Generally the details have been sorted out at some level otherwise how did you estimate it? And the ticket was likely estimated 2 months ago and you may not have been a part of that. I prefer a ticket with as much detail as possible so I'm not making the wrong assumptions.
  - jeff303 6y ago
    How do you prefer to gather the context for something that may have been hashed out months or years ago by different people?
    - SideburnsOfDoom 6y ago
      The idea that a task can and should be "hashed out months or years ago by different people" is part of the JIRA mentality. And it is absurd.
      - Hallucinaut 6y ago
        I dislike Jira, but it's quite untrue that it's absurd that there needs to be context and a record of discussion for tasks. People leave, focus changes, memories fade. It's not a unique occurrence that I wonder "why the hell is it done like this?!" only to find it was a decision I was part of with developers who had left in a least-worst-change trade-off. Jira or products like it help us avoid repeating the same mistakes. Put another way, part of the art is not just the code, but the code that's not there. Jira/tickets are one way of managing that data. And at other times, it's just a tool for bureaucracy, I get that.
      - xxpor 6y ago
        ... have you ever worked on a project involving multiple teams? I say this as someone who loathes JIRA but still exists in the real world where you need to collaborate to design something.
      - deleted 6y ago
        [deleted]
      - aprdm 6y ago
        heh you would be surprised. I literally closed a ticket from 2014 this week which had a lot of relevant information and prior discussion. Without the record of it somewhere I would of had taken much more time. I also always search jira for a particular issue that I am having to see if someone else has already solved it or a reason for it not to be solved. Sometimes it works quite well saving me a lot of time.
  - grogenaut 6y ago
    I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots. Yes I'm an assembly line robot and the plant foreman. Jira and delegation helped me pull off both
    - blargmaster42_8 6y ago
      Have done the same and it was glorious!
    - aprdm 6y ago
      Totally. I actually don't know how people that work in big enough organizations can possibly not like Jira (or a tool like it). I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.
      - aembleton 6y ago
        You'd probably end up recreating a rudimentary version of it in a spreadsheet
  - xeromal 6y ago
    Pretty sure that's what the majority of programmers are. I know I am. My identity isn't wrapped up in programming. I build stuff for a company that pays me lots of money and then I go home and do stuff I like. We need to get rid of this wild west mentality where disorganization is lauded.
    - guenthert 6y ago
      > My identity isn't wrapped up in programming. Fair enough and quite common I suppose. Generally for some a job is just that, for other (perhaps just some lucky few) it's a calling. I'd think the share of the former was large among programmers ("coders") in the early days of computing, when that wasn't a highly regarded job (seen alike data entry). Then a few years after the micro computer revolution, many of those who grew up and where fascinated by home computers entered the work force. Those you essentially just needed to feed and perhaps point in a direction. Then the Internet bubble happened and many realized that there was hard cash to be earned. There we have the career IT guy (who's just as happy to do something else which pays at least as much). It's not that they perform worse (in situation where discipline and organization is paramount they can be expected to outperform geeks), but the work style is quite different. > We need to get rid of this wild west mentality where disorganization is lauded. I don't think people celebrate their lack of discipline, but rigidity stymies creativity (and don't ask me how long it'll take me to fix a bug). I don't think Silicon Valley happened accidentally in California rather than in Prussia.
  - meddlepal 6y ago
    Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.
    - JoeAltmaier 6y ago
      And certainly there are better things.
      - meddlepal 6y ago
        Sure, with probably very different stability and risk profiles as well as entrance requirements.
mdoms 6y ago
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eyeball the ticket.
- marcc 6y ago
  I don't think the comment was implying that a manager has to eyeball the ticket to make it worthwhile. The comment said there's value in documenting the process, and I agree with that. We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have a record of the fix that's easy to find, track the conversation around it, and be able to reference it 6 months or later. Documenting how it was fixed and tested and verified is very useful. Having a place for a manager to eyeball tickets before they are working is not the value of the system.
  - d23 6y ago
    It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built. The necessity for documentation exists along a spectrum, and the means of documenting things exists along a spectrum. We have lots of tools for documentation. Design docs, commit messages, the commits themselves, JIRA, email, chat. Which one is appropriate depends on the given situation.
    - marcc 6y ago
      Who is claiming that if a bug fix fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all? That's not my intent as the parent here, or the point I'm seeing or picking up from this thread. There's value in documenting in a system (Jira is one choice), but I know that I'm certainly able to see value in building a system and a process and then trusting that developers use them when appropriate and know when they are not adding value.
SideburnsOfDoom 6y ago
> If devs aren't working on priority items Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.
- EpicEng 6y ago
  >and what happens when JIRA does not reflect the actual priority as observed by devs? Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.
  - x0x0 6y ago
    It's a common symptom of devs who undervalue the rest of the business. And who think that code magically turns into dollars without effort.
  - SideburnsOfDoom 6y ago
    > Why do you believe devs alone define the "actual priority"? This stuff is collaborative, I do not believe that, of course it is collaborative. Some things are emergent, some are not. Some can be neatly broken down into fixed length tasks, some cannot. Some are planned, some are not. Some are top-down, some are bottom up. Some are obvious business function items, some are leftfield ideas. I'm just feeding back that attempting to mediate and regulate that collaboration via JIRA is a bad idea. A common, and bad idea.
    - grendix 6y ago
      It's kind of weird how the subtext to every conversation in this topic is bad management, yet nobody wants to come out and say it.
      - SideburnsOfDoom 6y ago
Joeri 6y ago
This is a specific view of the role of the developer, one where a developer is not a stakeholder, has no agency, and is in essence a hired gun easily replaced by another hired gun. Products built like that tend to be the lowest quality, because the people actually making it don’t care about what they’re making. Teams run like that require detailed work tracking solutions with dedicated middle management. The other approach is to have developers build up a real sense of why they are building what they’re building, who they are building it for, and give them the agency to change the how and what to better meet that why. This requires trust, so it is more easily done in organizations that are on a first name basis. It may involve jira, but really almost any work tracking solution will work.
jakevoytko 6y ago
> Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based around short-term thinking. First, it provides multiple negotiations for every work stream: "What tickets are part of this project?" and inevitably "what tickets do we need to cut to get this project out the door faster?" The developer quality of life tickets are the easiest for non-engineers to jettison. What's worse, sometimes they're right to want to get rid of those tickets. Quite honestly, developers often don't do the math on "Will we ever get the time back we spend fixing this?" Second, JIRA-based systems are designed to try to make everything take the minimum possible time. This is a good thing, but developers can bear the burden of it. Quick iteration is good, but it turns into a situation where the most you can undershoot a task is by hours or a few days, but if something is much harder than you expect, it could overrun by weeks. I think this is a necessarily reality of business, and that "evidence-based scheduling" a-la Joel Spolsky is an innovation that could have eased this pain by introducing "how bad are long-tail effects?" into project planning. But as-is, you're in a situation where you're either meeting expectations (since the ticket took more-or-less what people thought), or you're visibly holding a project back (because it was tightly scheduled to within an inch of its life). So the development experience becomes this weird commodity that sometimes has really visible failure modes. And finally, since JIRA projects/epics/whatever are often prioritized by expected value, it's difficult to raise large engineering concerns. Again, this is a good thing, because time spent engineering is time not spent helping the customer. But because the focus of JIRA is so granular, it's difficult to break out of that. Imagine a company in the 80s that wrote desktop software in assembly, and some engineer is like, "This is crazy, we should invest the time to write modules in C". How do you climb out of that? In the language of agile development, you actually need a lot of foresight to break out of this local maxima, because your prototype will be demonstrably worse - "so we need to set up this compiler toolchain everywhere, and interface with our existing assembly code, which the compiler toolchain doesn't make easy, and it introduces ABI concerns, and your prototype looks worse than just going with this. I think we can safely call this a failed experiment." When the only project language you have is trees, it's difficult to talk about forest. I think this is why healthy engineering organizations that I've worked for tend to spend about 30% of their time working on more ambitious stuff. But it's something that needs to come from the top-down, because the tools won't provide it. So to developers, the structure imposes a system where successes are minor, failures are visible, it's hard to get negotiation leverage, you lose the forest for the trees, and they need to fight tooth-and-nail for quality of life improvements (or they get a week thrown down from above, as a treat, to address any technical debt).
runarberg 6y ago
A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer never has to write to it. The only JIRA a developer will be happy using is a JIRA they don’t have to work with.
- aplummer 6y ago
  You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...
  - runarberg 6y ago
    QA can be automated in the same way using CI/CD. A QA engineer should be able to read the existing process documents from the git history and have confidence in the CI/CD. In fact a QA engineer’s job is made easier if a robot is cataloging the process (as human developers are prone to errors and sloppy work). Regarding feedback, a developers dream is to never have to ask for one or give one. Tickets should be well formed and ready for the developer to start work efficiently. A customer service engineer is in the perfect spot to ease the work of the developer. If a developer has question they can ask the customer service engineer which in effect is responsible to document the process. Note that I pick JIRA apart here for no specific reason, it is possible to use GitHub as inefficiently as JIRA and vise versa. However GitHub has developer friendly workflow set up by default, whereas JIRA does not. In fact I’ve never seen a JIRA workflow that is developer friendly.
  - xxpor 6y ago
    The real disease is everyone having this separate QA step. QA is part of developing a feature. Do it yourself.
- tomashertus 6y ago
  You can automate the same thing with JIRA if you use bitbucket. I even saw process automation with Github and JIRA. This is just an excuse I heard from devs 100 times.
ogre_codes 6y ago
> And I've also never worked anywhere that had a better option than JIRA. Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about. Mainly: - Is the ticket ready for me to work on? (Do I have the designs I need to work it?) - Who is working on a given ticket right now? - Am I done with a ticket? - Is the ticket ready for QA? - Did QA reject the ticket and I need to fix something on the ticket? Pivotal does these things fairly well. There is also the obligatory pointing system, but the above is the bulk of what I care about. Pivotal also lets me create queries so I can zero in on the work which I'm doing as opposed to the entire project.
- TimTheTinker 6y ago
  GitHub does all of this very well. "Ticket" => GitHub issue "status" => current column on GitHub project. This includes "is the ticket ready for me", "am I done with a ticket", "is the ticket ready for QA", "did QA reject the ticket", etc. -- each of these is a column in the project board. "who is working on it" => assignee(s)
  - ogre_codes 6y ago
    I haven't used GitHub for this, so I'll take your word for it. The fact that there are a lot of ways to track these issues well was exactly my point. You need some way of tracking these things. I've used JIRA and it got the job done. I've also used other tools which worked as well. What doesn't scale is not tracking issues.
  - threeseed 6y ago
    It only does it well if you have extremely basic needs. It doesn't support custom attributes, workflows, approval hierarchies, statuses etc. There is a reason ZenHub had to be invented after all.
    - TimTheTinker 6y ago
      Custom attributes: use labels Workflows: set up one or more project boards and PR merge restrictions Approval hierarchies: where the above is inadequate, use CODEOWNERS files. Statuses: use project columns and labels
gurkendoktor 6y ago
> And developers are expensive as hell. Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems. I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true. </rant> And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.
- orzig 6y ago
  My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.
  - kiksy 6y ago
    Nice. This would likely solve a huge chunk of push back against JIRA.
    - ori_b 6y ago
      Yes, I'd also enjoy jira if the company would pay someone else to use it for me.
      - my_usernam3 6y ago
eriktate 6y ago
While I agree that it's for managers and stakeholders, I wonder how much of it ends up being a net value-add. Where I work, we have a million and one different kinds of reports that pass through the chain of command (admittedly not all of these are derived from Jira, but they exist for the same reasons). We then end up with arbitrary, company-wide reporting requirements that for a lot of teams are like fitting a square peg in a round hole. Then, when you show up as non-compliant on the report that doesn't actually say anything valuable about your team or project, you have to drop everything and shoehorn some solution to make the report happy even though there's precisely zero value added (I would argue a net loss because time and effort is wasted while adding zero value). All because inconsistencies in the reporting aren't tolerated since upper management can't be bothered to understand even the smallest amount of nuance. I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.
deleted 6y ago
[deleted]
OwlsParlay 6y ago
I've not used JIRA in the long time, but in general I find source coontrol with issue tracking to be highly useful for working out why a particular change was made, several months after the fact, even if I wasn't the developer responsible (or even in the team).
specialist 6y ago
> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.
- p2t2p 6y ago
  > They don't. Funny. Can I get $100 please? Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things. We have very simple process in our team with two issue types for devs - task and bug. We have two week long sprints and put tasks from backlog into them. Statuses are: open, in progress, code review, done. If I forgot to move a ticket than a team lead or feature lead will do that for me whenever they are at it. Besides this there are epics but devs don't deal with them, feature leads and team leads and PMs do. This is all running on an instance that is deployed every 4 hours with changes from master and goes through the same upgrade process our customers would go. There's special set of very high-level tickets but we don't deal with those, those are for for people 3 levels above. Sprint planning is about 30 minutes because backlog grooming is done for devs by feature leads and team leads and that's pretty much the only obligatory meeting.
  - specialist 6y ago
    Sure. Post the video(s) and a Venmo account. > Sprint planning is about 30 minutes... That's like saying Santa Klaus is real. I want to believe you. I really do.
    - p2t2p 6y ago
      By the time we're in planning, only things to discuss is estimation and priority, it takes virtually no time. We have a whole hour booked and spend half of it to just hang out, pretty much the only time where the whole team is present in one meeting.
ajkjk 6y ago
I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't know how to think about that at all. A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort. More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables. Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.
- ryandrake 6y ago
  > The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up. Let's take two projects. Project A is estimated by the eng team to take three months to complete. It's not broken down into tasks that are individually estimated and tracked. Just one monolithic task: Do Project A. The project manager says "go!" and then leaves the tech lead to basically run open loop, maybe with a monthly "So, how are things going, eh?" conversation. Project B is estimated by the engineering team to take three months, but is then broken into small week-long sub-projects, and days-long sub-tasks, highlighting dependencies. After stacking the tasks up and assigning them to the team, it looks like the project will actually take four months. Throughout development, new tasks are created as bugs are found and assigned priorities. The project manager and eng lead watches the finished/remaining task lists daily or weekly, and can easily tell when something is taking much longer or much shorter than expected, and what other parts that depend on that will be delayed. Which project do you think has the best chance of making its estimated complete date? If the complete date is actually a deadline, which project can be more easily re-sized half way through if we need to cut scope in order to make it? Which project can the team's boss's boss's boss more easily obtain status information about? How does anyone besides the eng lead know whether Project A is even done?
dblohm7 6y ago
> Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. So much for Agile!
- Viliam1234 6y ago
  Seems like the only refactoring supported by Agile is managers refactoring Agile itself.
wpietri 6y ago
You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices. If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, everybody here knows that's not true. I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something. [1] https://en.wikipedia.org/wiki/Managerialism https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/ https://www.amazon.com/dp/B00A76WZ96/
- namdnay 6y ago
  I think it’s important to realise that the vast majority (I’m sure it’s more than 90%) of software development being done is technical people from enterprise A building something to help nontechnical people from enterprise B with process C. That’s not something that startups have ever competed with, for good reason. I love startups and I love working on that space, but you must stay aware that it’s a tiny galaxy within a much larger universe of software that is built and sold like any other engineering project. And in this “enterprise” (for want of a better word) space, management is important. Not because managers are omniscient or omnipotent, but because at the end of the day, when a customer is paying a large amount of money for something intangible, they need people to talk to, they need figures to see, they need metrics. And in business, the customer is king. Again, except for the startup galaxy where customers are two a penny
  - wpietri 6y ago
    Startups compete in the enterprise space all the time, [1], so I don't think your characterization is correct. I agree that client relations is important, but that's something that happens in many businesses. Like the comment I replied to, you assert that a managerial apparatus is necessary for that. I don't think that's the case. It's true that managerialist-dominated companies often prefer to work with other companies of a similar culture. But that doesn't have anything to do with what makes for efficient software engineering. [1] e.g.: https://www.computerworld.com/article/3412380/the-hottest-enterprise-tech-startups-to-watch-in-2020.html https://www.computerworld.com/article/3412380/the-hottest-en...
prepend 6y ago
I once worked with a developer on a relatively small team of 10 people or so (3 other devs) who said it was impossible and pointless to estimate effort for tasks. He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done. It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard. After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes. It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams. This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on. This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.
- pm90 6y ago
  You want devs to not care about anything but fixing technical problems though. At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are meant for. I do agree with you that it’s not practical to spend infinite time on fixing a problem. But it’s not strange for an engineer to think that way; in fact engineers who are willing to dig deep and at least root cause the issues (if not outright fix them) are very valuable to have.
  - prepend 6y ago
    The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.
deleted 6y ago
[deleted]
adrr 6y ago
I worked at an org where you couldn’t do anything without and being assigned a Jira ticket. Want to refactor some code so the feature your working on is maintainable, nope you need an assigned Jira ticket. The fact that work units are called tickets and Jira was built originally for desktop support is the foundation of the problem. Don’t think, just code attitude. Anything is better than Jira including post it notes on a wall.
- ryandrake 6y ago
  Why is this a problem? Was it difficult to create a Jira ticket? When last i used Jira, it took a few seconds to create one. Less time than it takes to write a commit message.
  - RogerL 6y ago
    Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to somebody that essentially knows nothing about it, because developers are interchangable, don't you know? Meanwhile you are stalled because that refactor made sense to do before the ticket you are working on. So you work on that one, don't move it to complete, and get dinged. Or you do it anyway, knowing you will have to do the work a second time once the refactor is done, but hey, you'll get so move multiple tickets to 'ready for test' next sprint or so, so yay, you measure well, can't wait for bonus time! Yes, I just described a horrible process, but pretty much how it goes in most places. The very first thing people forget, and fight strenuously against, is the agile principle "people, not process" To offer the counterpoint, if I am refactoring sw that runs in a flight computer or something, even more process is needed, because you need to test extensively before releasing code that can kill someone. That check in can cost hundreds of thousands of dollars if you touched something that is now going to have to go through lengthy QA. It just depends on where you work, and the cost of bugs vs rapid response to problems/requests. In my experience orgs try to build a workflow that would suit the space shuttle when the product is, well, less important and serious.
pmoriarty 6y ago
"Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets." It's for developers too. As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc. Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue. This is the strength of a ticket tracking system, and that strength helps everyone.
grumple 6y ago
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. This is patently false, as evidenced by every business in existence that doesn't use issue trackers, including most non-tech divisions of current businesses and most tech businesses until the rise of agile. And I question the value add of these things; my current company was built without them, and it's only as we've matured (well after the product was built and mostly refined) that issue tracking was used.
Aeolun 6y ago
> But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. Yeah. The problem is they now have to report at least 50% less progress because half of s dev’s mental power is dedicated to ignoring or updating Jira.
throwaway189262 6y ago
>>> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed. >>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious. It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at. There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.

by tootie 6y ago

TheFunkyMonk 6y ago

I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.

SideburnsOfDoom 6y ago
You are an assembly line robot.
- kiaulen 6y ago
  This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.
  - SideburnsOfDoom 6y ago
    > Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".
    - turbinerneiter 6y ago
      Exactly. What's going on is commits and merges. They live in GitLab. There is also tickets in GitLab, which all developers are happy to use. There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites! But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is another platform with a complex and slow ui, and our docs formerly markdown are now in some proprietary confluence RTF, which can export to word and PDF - with no custom styling.
      - novok 6y ago
        I haven't used gitlab's wiki specifically, but the reason why you would use something like confluence is because you get a wiki with a wysiwyg editor, so less technical people can use it without having to learn markdown and there is less friction to making docs. It's not specific to confluence. Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.
        turbinerneiter 6y ago
        I'd argue that Markdown is easier to learn than confluence wysiwyg, and also more useful in the long run. Especially as there are many GUI Markdown editors with buttons and preview windows, that give you best of both worlds.
      - deleted 6y ago
        [deleted]
      - deleted 6y ago
        [deleted]
      - pm90 6y ago
        The constraint for the org I work in is that GitHub has a per user license fee that makes it difficult to justify getting a license for everyone in the org since we have a lot of non developer staff. But everyone has access to confluence/JIRA. Does Gitlab also have similar license restrictions?
- TheFunkyMonk 6y ago
  Do you prefer to... not have all the details in front of you for a task you're about to work on?
  - stefanmichael 6y ago
    Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you. As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company, etc. edit: anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone
    - reificator 6y ago
      > anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone I would, but that's a detail that a senior dev like yourself should be able to figure out without people just providing it for you.
    - majewsky 6y ago
      I agree with your assessment, having experienced a gradual shift from junior to senior myself. As for why the downvotes, hypothesis 1: People might misconstrue your position as "senior ICs are supposed to design the system entirely on their own". I understand you as "management provides the direction and some design constraints, seniors fill in the details, juniors just implement specifications from the seniors", which matches my experience. Hypothesis 2: Maybe it's a culture thing? I'm guessing from your user name that you're from Europe, and I'm from Germany. Maybe the downvoters are literally coming from a different place? (Don't know how it would be different over there though.)
    - codenesium 6y ago
      Generally the details have been sorted out at some level otherwise how did you estimate it? And the ticket was likely estimated 2 months ago and you may not have been a part of that. I prefer a ticket with as much detail as possible so I'm not making the wrong assumptions.
- jeff303 6y ago
  How do you prefer to gather the context for something that may have been hashed out months or years ago by different people?
  - SideburnsOfDoom 6y ago
    The idea that a task can and should be "hashed out months or years ago by different people" is part of the JIRA mentality. And it is absurd.
    - Hallucinaut 6y ago
      I dislike Jira, but it's quite untrue that it's absurd that there needs to be context and a record of discussion for tasks. People leave, focus changes, memories fade. It's not a unique occurrence that I wonder "why the hell is it done like this?!" only to find it was a decision I was part of with developers who had left in a least-worst-change trade-off. Jira or products like it help us avoid repeating the same mistakes. Put another way, part of the art is not just the code, but the code that's not there. Jira/tickets are one way of managing that data. And at other times, it's just a tool for bureaucracy, I get that.
    - xxpor 6y ago
      ... have you ever worked on a project involving multiple teams? I say this as someone who loathes JIRA but still exists in the real world where you need to collaborate to design something.
    - deleted 6y ago
      [deleted]
    - aprdm 6y ago
      heh you would be surprised. I literally closed a ticket from 2014 this week which had a lot of relevant information and prior discussion. Without the record of it somewhere I would of had taken much more time. I also always search jira for a particular issue that I am having to see if someone else has already solved it or a reason for it not to be solved. Sometimes it works quite well saving me a lot of time.
- grogenaut 6y ago
  I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots. Yes I'm an assembly line robot and the plant foreman. Jira and delegation helped me pull off both
  - blargmaster42_8 6y ago
    Have done the same and it was glorious!
  - aprdm 6y ago
    Totally. I actually don't know how people that work in big enough organizations can possibly not like Jira (or a tool like it). I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.
    - aembleton 6y ago
      You'd probably end up recreating a rudimentary version of it in a spreadsheet
- xeromal 6y ago
  Pretty sure that's what the majority of programmers are. I know I am. My identity isn't wrapped up in programming. I build stuff for a company that pays me lots of money and then I go home and do stuff I like. We need to get rid of this wild west mentality where disorganization is lauded.
  - guenthert 6y ago
    > My identity isn't wrapped up in programming. Fair enough and quite common I suppose. Generally for some a job is just that, for other (perhaps just some lucky few) it's a calling. I'd think the share of the former was large among programmers ("coders") in the early days of computing, when that wasn't a highly regarded job (seen alike data entry). Then a few years after the micro computer revolution, many of those who grew up and where fascinated by home computers entered the work force. Those you essentially just needed to feed and perhaps point in a direction. Then the Internet bubble happened and many realized that there was hard cash to be earned. There we have the career IT guy (who's just as happy to do something else which pays at least as much). It's not that they perform worse (in situation where discipline and organization is paramount they can be expected to outperform geeks), but the work style is quite different. > We need to get rid of this wild west mentality where disorganization is lauded. I don't think people celebrate their lack of discipline, but rigidity stymies creativity (and don't ask me how long it'll take me to fix a bug). I don't think Silicon Valley happened accidentally in California rather than in Prussia.
- meddlepal 6y ago
  Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.
  - JoeAltmaier 6y ago
    And certainly there are better things.
    - meddlepal 6y ago
      Sure, with probably very different stability and risk profiles as well as entrance requirements.

mdoms 6y ago

> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eyeball the ticket.

marcc 6y ago
I don't think the comment was implying that a manager has to eyeball the ticket to make it worthwhile. The comment said there's value in documenting the process, and I agree with that. We use a ticketing system to track work. It's not Jira. But we do have a requirement that all work is tracked in that system. It's not so that a Product Manager or Engineering Manager can chime in and micromanage; it's so that we have a record of the fix that's easy to find, track the conversation around it, and be able to reference it 6 months or later. Documenting how it was fixed and tested and verified is very useful. Having a place for a manager to eyeball tickets before they are working is not the value of the system.
- d23 6y ago
  It's just so obviously an absurd statement to say that if a bug is fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all. A huge portion of the day to day work of software engineering happens without explicit documentation of every decision for every change for every line of code. Life continues, software is built. The necessity for documentation exists along a spectrum, and the means of documenting things exists along a spectrum. We have lots of tools for documentation. Design docs, commit messages, the commits themselves, JIRA, email, chat. Which one is appropriate depends on the given situation.
  - marcc 6y ago
    Who is claiming that if a bug fix fixed and not documented meticulously in JIRA it is as useless as if it was never fixed at all? That's not my intent as the parent here, or the point I'm seeing or picking up from this thread. There's value in documenting in a system (Jira is one choice), but I know that I'm certainly able to see value in building a system and a process and then trusting that developers use them when appropriate and know when they are not adding value.

SideburnsOfDoom 6y ago

> If devs aren't working on priority items Define how something comes to be a "priority item", who decides, and what happens when JIRA does not reflect the actual priority as observed by devs? If the answer is "more JIRA" then you're already failing.

EpicEng 6y ago
>and what happens when JIRA does not reflect the actual priority as observed by devs? Why do you believe devs alone define the "actual priority"? This stuff is collaborative, and I've worked with many devs who don't have the first clue as to what needs to be built by when in order to keep the business thriving.
- x0x0 6y ago
  It's a common symptom of devs who undervalue the rest of the business. And who think that code magically turns into dollars without effort.
- SideburnsOfDoom 6y ago
  > Why do you believe devs alone define the "actual priority"? This stuff is collaborative, I do not believe that, of course it is collaborative. Some things are emergent, some are not. Some can be neatly broken down into fixed length tasks, some cannot. Some are planned, some are not. Some are top-down, some are bottom up. Some are obvious business function items, some are leftfield ideas. I'm just feeding back that attempting to mediate and regulate that collaboration via JIRA is a bad idea. A common, and bad idea.
  - grendix 6y ago
    It's kind of weird how the subtext to every conversation in this topic is bad management, yet nobody wants to come out and say it.
    - SideburnsOfDoom 6y ago

Joeri 6y ago

This is a specific view of the role of the developer, one where a developer is not a stakeholder, has no agency, and is in essence a hired gun easily replaced by another hired gun. Products built like that tend to be the lowest quality, because the people actually making it don’t care about what they’re making. Teams run like that require detailed work tracking solutions with dedicated middle management. The other approach is to have developers build up a real sense of why they are building what they’re building, who they are building it for, and give them the agency to change the how and what to better meet that why. This requires trust, so it is more easily done in organizations that are on a first name basis. It may involve jira, but really almost any work tracking solution will work.

jakevoytko 6y ago

> Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. As someone who dislikes JIRA but likes process, I agree with this. The way that JIRA structures projects has specific tradeoffs that disadvantage developers and advantage middle managers because it's entirely based around short-term thinking. First, it provides multiple negotiations for every work stream: "What tickets are part of this project?" and inevitably "what tickets do we need to cut to get this project out the door faster?" The developer quality of life tickets are the easiest for non-engineers to jettison. What's worse, sometimes they're right to want to get rid of those tickets. Quite honestly, developers often don't do the math on "Will we ever get the time back we spend fixing this?" Second, JIRA-based systems are designed to try to make everything take the minimum possible time. This is a good thing, but developers can bear the burden of it. Quick iteration is good, but it turns into a situation where the most you can undershoot a task is by hours or a few days, but if something is much harder than you expect, it could overrun by weeks. I think this is a necessarily reality of business, and that "evidence-based scheduling" a-la Joel Spolsky is an innovation that could have eased this pain by introducing "how bad are long-tail effects?" into project planning. But as-is, you're in a situation where you're either meeting expectations (since the ticket took more-or-less what people thought), or you're visibly holding a project back (because it was tightly scheduled to within an inch of its life). So the development experience becomes this weird commodity that sometimes has really visible failure modes. And finally, since JIRA projects/epics/whatever are often prioritized by expected value, it's difficult to raise large engineering concerns. Again, this is a good thing, because time spent engineering is time not spent helping the customer. But because the focus of JIRA is so granular, it's difficult to break out of that. Imagine a company in the 80s that wrote desktop software in assembly, and some engineer is like, "This is crazy, we should invest the time to write modules in C". How do you climb out of that? In the language of agile development, you actually need a lot of foresight to break out of this local maxima, because your prototype will be demonstrably worse - "so we need to set up this compiler toolchain everywhere, and interface with our existing assembly code, which the compiler toolchain doesn't make easy, and it introduces ABI concerns, and your prototype looks worse than just going with this. I think we can safely call this a failed experiment." When the only project language you have is trees, it's difficult to talk about forest. I think this is why healthy engineering organizations that I've worked for tend to spend about 30% of their time working on more ambitious stuff. But it's something that needs to come from the top-down, because the tools won't provide it. So to developers, the structure imposes a system where successes are minor, failures are visible, it's hard to get negotiation leverage, you lose the forest for the trees, and they need to fight tooth-and-nail for quality of life improvements (or they get a week thrown down from above, as a treat, to address any technical debt).

runarberg 6y ago

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer never has to write to it. The only JIRA a developer will be happy using is a JIRA they don’t have to work with.

aplummer 6y ago
You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...
- runarberg 6y ago
  QA can be automated in the same way using CI/CD. A QA engineer should be able to read the existing process documents from the git history and have confidence in the CI/CD. In fact a QA engineer’s job is made easier if a robot is cataloging the process (as human developers are prone to errors and sloppy work). Regarding feedback, a developers dream is to never have to ask for one or give one. Tickets should be well formed and ready for the developer to start work efficiently. A customer service engineer is in the perfect spot to ease the work of the developer. If a developer has question they can ask the customer service engineer which in effect is responsible to document the process. Note that I pick JIRA apart here for no specific reason, it is possible to use GitHub as inefficiently as JIRA and vise versa. However GitHub has developer friendly workflow set up by default, whereas JIRA does not. In fact I’ve never seen a JIRA workflow that is developer friendly.
- xxpor 6y ago
  The real disease is everyone having this separate QA step. QA is part of developing a feature. Do it yourself.
tomashertus 6y ago
You can automate the same thing with JIRA if you use bitbucket. I even saw process automation with Github and JIRA. This is just an excuse I heard from devs 100 times.

ogre_codes 6y ago

> And I've also never worked anywhere that had a better option than JIRA. Agree with most of what you say aside from this bit. I find most similar systems are in the same ballpark in terms of being able to track what I care about. Mainly: - Is the ticket ready for me to work on? (Do I have the designs I need to work it?) - Who is working on a given ticket right now? - Am I done with a ticket? - Is the ticket ready for QA? - Did QA reject the ticket and I need to fix something on the ticket? Pivotal does these things fairly well. There is also the obligatory pointing system, but the above is the bulk of what I care about. Pivotal also lets me create queries so I can zero in on the work which I'm doing as opposed to the entire project.

TimTheTinker 6y ago
GitHub does all of this very well. "Ticket" => GitHub issue "status" => current column on GitHub project. This includes "is the ticket ready for me", "am I done with a ticket", "is the ticket ready for QA", "did QA reject the ticket", etc. -- each of these is a column in the project board. "who is working on it" => assignee(s)
- ogre_codes 6y ago
  I haven't used GitHub for this, so I'll take your word for it. The fact that there are a lot of ways to track these issues well was exactly my point. You need some way of tracking these things. I've used JIRA and it got the job done. I've also used other tools which worked as well. What doesn't scale is not tracking issues.
- threeseed 6y ago
  It only does it well if you have extremely basic needs. It doesn't support custom attributes, workflows, approval hierarchies, statuses etc. There is a reason ZenHub had to be invented after all.
  - TimTheTinker 6y ago
    Custom attributes: use labels Workflows: set up one or more project boards and PR merge restrictions Approval hierarchies: where the above is inadequate, use CODEOWNERS files. Statuses: use project columns and labels

gurkendoktor 6y ago

> And developers are expensive as hell. Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems. I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true. </rant> And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.

orzig 6y ago
My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.
- kiksy 6y ago
  Nice. This would likely solve a huge chunk of push back against JIRA.
  - ori_b 6y ago
    Yes, I'd also enjoy jira if the company would pay someone else to use it for me.
    - my_usernam3 6y ago

eriktate 6y ago

While I agree that it's for managers and stakeholders, I wonder how much of it ends up being a net value-add. Where I work, we have a million and one different kinds of reports that pass through the chain of command (admittedly not all of these are derived from Jira, but they exist for the same reasons). We then end up with arbitrary, company-wide reporting requirements that for a lot of teams are like fitting a square peg in a round hole. Then, when you show up as non-compliant on the report that doesn't actually say anything valuable about your team or project, you have to drop everything and shoehorn some solution to make the report happy even though there's precisely zero value added (I would argue a net loss because time and effort is wasted while adding zero value). All because inconsistencies in the reporting aren't tolerated since upper management can't be bothered to understand even the smallest amount of nuance. I know most of the people in these positions aren't _actually_ stupid, and would agree if you were able to explain to them why some specific thing is completely irrelevant, or even detrimental, to your team. At the end of the day, though, at big orgs no one cares. They'll waste as much time and effort as necessary in order to look good on metrics. Even if the metrics are worthless.

deleted 6y ago

[deleted]

OwlsParlay 6y ago

I've not used JIRA in the long time, but in general I find source coontrol with issue tracking to be highly useful for working out why a particular change was made, several months after the fact, even if I wasn't the developer responsible (or even in the team).

specialist 6y ago

> ...you haven't documented the process... How does JIRA help with that? I'd LOVE an unauthorized documentary revealing how Atlassian dog foods JIRA. My $100 bet: They don't. While Atlassian has great confidence for how you should run your projects, what they do internally bears no resemblance to that sage advice.

p2t2p 6y ago
> They don't. Funny. Can I get $100 please? Every team has their own process that is tailored to their needs, process is decided by devs, not managers, managers only do "I'd like to have this kind of visibility" requests some times and I yet to see those requests introducing any kind of burden, usually very miniscule things. We have very simple process in our team with two issue types for devs - task and bug. We have two week long sprints and put tasks from backlog into them. Statuses are: open, in progress, code review, done. If I forgot to move a ticket than a team lead or feature lead will do that for me whenever they are at it. Besides this there are epics but devs don't deal with them, feature leads and team leads and PMs do. This is all running on an instance that is deployed every 4 hours with changes from master and goes through the same upgrade process our customers would go. There's special set of very high-level tickets but we don't deal with those, those are for for people 3 levels above. Sprint planning is about 30 minutes because backlog grooming is done for devs by feature leads and team leads and that's pretty much the only obligatory meeting.
- specialist 6y ago
  Sure. Post the video(s) and a Venmo account. > Sprint planning is about 30 minutes... That's like saying Santa Klaus is real. I want to believe you. I really do.
  - p2t2p 6y ago
    By the time we're in planning, only things to discuss is estimation and priority, it takes virtually no time. We have a whole hour booked and spend half of it to just hang out, pretty much the only time where the whole team is present in one meeting.

ajkjk 6y ago

I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't know how to think about that at all. A big engineering endeavor is more like an artistic endeavor that takes multiple people, like a giant sculpture or mural or something, than it is like a construction project. The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion, and then step back and let them work. They don't need to be delivering tasks on any specific cadence; they need to deliver the overall effort. More importantly, a tech team needs to be free to do a good job of owning the work they're doing. Properly owning and being invested in something feels basically impossible when someone is demanding you complete little one-off tasks for them -- good technical ownership means having the time and space to zoom out and fix systemic problems, rather than always chasing the next sprint's deliverables. Of course then the manager comes along and says: well, why don't you just track the systemic problems that you want to fix in Jira? And it seems like a good idea but it ruins it. Having to document and schedule everything you do is completely in opposition to doing the kind of passionate, obsessive engineering that produces the good results.

ryandrake 6y ago
> The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up. Let's take two projects. Project A is estimated by the eng team to take three months to complete. It's not broken down into tasks that are individually estimated and tracked. Just one monolithic task: Do Project A. The project manager says "go!" and then leaves the tech lead to basically run open loop, maybe with a monthly "So, how are things going, eh?" conversation. Project B is estimated by the engineering team to take three months, but is then broken into small week-long sub-projects, and days-long sub-tasks, highlighting dependencies. After stacking the tasks up and assigning them to the team, it looks like the project will actually take four months. Throughout development, new tasks are created as bugs are found and assigned priorities. The project manager and eng lead watches the finished/remaining task lists daily or weekly, and can easily tell when something is taking much longer or much shorter than expected, and what other parts that depend on that will be delayed. Which project do you think has the best chance of making its estimated complete date? If the complete date is actually a deadline, which project can be more easily re-sized half way through if we need to cut scope in order to make it? Which project can the team's boss's boss's boss more easily obtain status information about? How does anyone besides the eng lead know whether Project A is even done?

dblohm7 6y ago

Viliam1234 6y ago
Seems like the only refactoring supported by Agile is managers refactoring Agile itself.

wpietri 6y ago

You express a number of notions here that are part of the fantasy of managerialism [1]. An especially big one is that if we render all important decisions unto a managerial class, they will make optimal choices. If that were true, startups would never succeed, because established companies would use their greater resources and market power to gobble up market niches before startups could get momentum. In practice, everybody here knows that's not true. I think the true way to optimal resource usage is not through ever-increasing process and managerial layering. Instead, it's through tight feedback loops where small cross-functional teams iterate closely with the people they're serving. Which is exactly how most good startups work. If you were really right about pursuing a financial optimum, the first thing (very resource-constrained) startups would do is get a copy of JIRA and hire some middle managers to carefully parcel out the work against precisely designed specs and timelines. That they don't should tell you something. [1] https://en.wikipedia.org/wiki/Managerialism https://en.wikipedia.org/wiki/Managerialism, and also see https://www.amazon.com/dp/B00A76WZ96/ https://www.amazon.com/dp/B00A76WZ96/

namdnay 6y ago
I think it’s important to realise that the vast majority (I’m sure it’s more than 90%) of software development being done is technical people from enterprise A building something to help nontechnical people from enterprise B with process C. That’s not something that startups have ever competed with, for good reason. I love startups and I love working on that space, but you must stay aware that it’s a tiny galaxy within a much larger universe of software that is built and sold like any other engineering project. And in this “enterprise” (for want of a better word) space, management is important. Not because managers are omniscient or omnipotent, but because at the end of the day, when a customer is paying a large amount of money for something intangible, they need people to talk to, they need figures to see, they need metrics. And in business, the customer is king. Again, except for the startup galaxy where customers are two a penny
- wpietri 6y ago
  Startups compete in the enterprise space all the time, [1], so I don't think your characterization is correct. I agree that client relations is important, but that's something that happens in many businesses. Like the comment I replied to, you assert that a managerial apparatus is necessary for that. I don't think that's the case. It's true that managerialist-dominated companies often prefer to work with other companies of a similar culture. But that doesn't have anything to do with what makes for efficient software engineering. [1] e.g.: https://www.computerworld.com/article/3412380/the-hottest-enterprise-tech-startups-to-watch-in-2020.html https://www.computerworld.com/article/3412380/the-hottest-en...

prepend 6y ago

I once worked with a developer on a relatively small team of 10 people or so (3 other devs) who said it was impossible and pointless to estimate effort for tasks. He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done. It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard. After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes. It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams. This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on. This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.

pm90 6y ago
You want devs to not care about anything but fixing technical problems though. At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are meant for. I do agree with you that it’s not practical to spend infinite time on fixing a problem. But it’s not strange for an engineer to think that way; in fact engineers who are willing to dig deep and at least root cause the issues (if not outright fix them) are very valuable to have.
- prepend 6y ago
  The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.

deleted 6y ago

[deleted]

adrr 6y ago

I worked at an org where you couldn’t do anything without and being assigned a Jira ticket. Want to refactor some code so the feature your working on is maintainable, nope you need an assigned Jira ticket. The fact that work units are called tickets and Jira was built originally for desktop support is the foundation of the problem. Don’t think, just code attitude. Anything is better than Jira including post it notes on a wall.

ryandrake 6y ago
Why is this a problem? Was it difficult to create a Jira ticket? When last i used Jira, it took a few seconds to create one. Less time than it takes to write a commit message.
- RogerL 6y ago
  Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to somebody that essentially knows nothing about it, because developers are interchangable, don't you know? Meanwhile you are stalled because that refactor made sense to do before the ticket you are working on. So you work on that one, don't move it to complete, and get dinged. Or you do it anyway, knowing you will have to do the work a second time once the refactor is done, but hey, you'll get so move multiple tickets to 'ready for test' next sprint or so, so yay, you measure well, can't wait for bonus time! Yes, I just described a horrible process, but pretty much how it goes in most places. The very first thing people forget, and fight strenuously against, is the agile principle "people, not process" To offer the counterpoint, if I am refactoring sw that runs in a flight computer or something, even more process is needed, because you need to test extensively before releasing code that can kill someone. That check in can cost hundreds of thousands of dollars if you touched something that is now going to have to go through lengthy QA. It just depends on where you work, and the cost of bugs vs rapid response to problems/requests. In my experience orgs try to build a workflow that would suit the space shuttle when the product is, well, less important and serious.

pmoriarty 6y ago

"Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets." It's for developers too. As a developer I want to know what the history of work on a certain issue was, who requested it and who worked on it in the past (not just at the code level, the information for which should be in version control logs, but also at non-code levels like approval, review, etc), what the communication was with other stakeholders, etc. Much of this information is useful to me to figure out who to talk to if I have some questions which the documentation or sourcecode does not answer, and also how to communicate how/what was done on this issue. This is the strength of a ticket tracking system, and that strength helps everyone.

grumple 6y ago

> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. This is patently false, as evidenced by every business in existence that doesn't use issue trackers, including most non-tech divisions of current businesses and most tech businesses until the rise of agile. And I question the value add of these things; my current company was built without them, and it's only as we've matured (well after the product was built and mostly refined) that issue tracking was used.

Aeolun 6y ago

> But it's not for them. It's for managers and stakeholders who have to report progress and who are responsible for budgets. Yeah. The problem is they now have to report at least 50% less progress because half of s dev’s mental power is dedicated to ignoring or updating Jira.

throwaway189262 6y ago

>>> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Hard disagree. Unless you're writing software for clients a crapton of ceremony goes into JIRA tickets when 99.9% of them will never be looked at again once marked closed. >>> If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. JIRA is used when companies have no trust in their devs. We all use Git. There's a perfect, permanent record of anything I ever touch. Yet management is always worried we're going to "get distracted". As if that wouldn't be incredibly obvious. It's like hiring a plumber to fix something then following them around the house to make sure they don't straighten your artwork or do the dishes while they're at at. There's a pervasive theme that "PM knows best" among companies obsessed with JIRA. The best companies I worked at had no project managers at all and things ran great.