The Return of Fancy Tools(macwright.com) |
The Return of Fancy Tools(macwright.com) |
My thoughts:
* JIRA, still heavily used in many, many places. Not even close to being replaced in them.
* Evernote vs. Markdown: I have been using org mode and or plain text notes for over 20 years. Markdown was a welcome addition to the arsenal, but I tried the Evernote/Microsoft Notes back in the day... just went back to plaintext for notes+todo, it has worked forever and is good enough. Org mode is a very nice and "Fancy" tool on its own. But also easy to get started with.
Just some examples. I don't mean to be overly critical, it is an interesting and fun article about the tools we use as technologists, but it could do with a lot better grounding all around.
There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling.
I'll use the one that integrates with so many of our systems and, though flawed, does a great job.
Is most of that work waiting for Jira to respond to your action so you can take the next action?
I don't know if it's possible to have an adequately fast installation of Jira (since I've never seen one in a decade of Jira use at various places), but I do notice that people who have to put a lot of things into Jira seem to mostly use text editors or word processors to actually plan, and then transfer it a piece at a time into Jira once the initial result is done. Yesterday I was in a planning session with two others, and we did that planning with headings, bullet points, and concurrent editing by all three of us in a Google doc.
It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another. You can do the integration yourself, but it's a gigantic PITA, and as the number of tools rises, the number of integrations you need to set up is going to rise terrifyingly fast.
I have a litany of complaints about the Atlassian suite, but none of the competitors have even have the services we need.
I remember when we used Trac on a project and it seemed so primitive in many ways, but as soon as I had to use something baroque (broke), I wanted to go back to Trac.
Not to say that Trac isn’t fancy, it just chose a very specific dimension of fancy to focus on and ignored anything else.
It shouldn't though. Jira wasn't always here, and it wont be here forever.
And what's even more important, and is the point of the post, trends don't stay the same, whether a tool still maintains its existing userbase or even increases it.
In a changing market, a tool might hold or even increase its userbase, but still end up with much smaller marketshare.
If we add qualitative considerations too, then it's also very possible a tool to remain dominant even in market share, but still lose mindshare (and eventually be dropped by the next gen of developers).
Tons of people and companies use Visual Basic too, but it's not where things are happening (or what one should study to get a job in 2021).
I’d argue that ease-of-starting also includes how visible something is, since you can quickly find it and find resources for it. Most text editors don’t have org mode or have a small, half baked subset of it at best.
A lot of amazing adjectives apply to org mode. Ease of use isn’t it until it climbs over the emacs wall.
Not trying to be combative. I’d love if more people used org. Would love to be educated here if something I said isn’t accurate.
It's well understood that some people have "always used" IDEs, and other people have "always used" Vim/Emacs.
The post is about general trends. What kinds of tools were trending/rising at some point, what at another at so on.
In that sense, counter-examples don't negate a statistical observation. Only whether the trends described in it is right or wrong matters, not whether some or even many buck them.
The fact that there's such a wide range of options doesn't hurt. I'm currently using Logseq for note-taking (yeah, I actually had to look up the name. That's how bad my memory is) and it's been a considerable help there. VSCode, well, I use it with custom task setups that script as much of the manual work that I'd be likely to slip up on as possible.
Not everyone needs that sort of thing. I didn't 20 years ago.
So, yeah, I agree with what you're saying-- different tools for different needs.
When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently using Jira or is going to adopt it.
In JIRA it is completely impossible. A task has one project and one status. You're lucky to have view and comment rights on another team's task, forget about change-status or reassign. An admin can "move" an issue but then it's gone from your own world.
The net result: the issue tracker is no longer a communications medium, but a paper trail for the bean-counters, where you laboriously log conversations and decisions that actually occurred by email or Slack. There will be a JIRA corresponding to any give issue, but reading the JIRA will not tell you the story anymore.
no it was not. people didn't migrate from VS to Sublime, they migrated from notepad++ to Sublime. I have never met anyone who stopped using IDEs once they started, except maybe for VSCode with a few hundred plug-ins to reconstruct an IDE piece-wise (but with much less "integration" between the different plug-ins)
I actually got introduced to it in ICT lessons at high school.
Oh Adobe. The memory of their software is so nostalgic. Don't get me started, I'll be talking about macromedia shockwave next...
Good tools should be easy to approach with the ability to customize and do more advanced actions, but never difficult
Good tools and products encapsulate complexity but still allow access to it where needed.
Good tools aim to simplify complexity, not complexify simplicity.
Good engineers and product people make tools that aim to simplify. Make it approachable to a n00b/junior but no bullshit for the experienced, or at least the ability to turn off the bullshit and lock-in. Always aim to abstract complexity into simplicity, that is the job.
Also most of the professional writers I know don't write in Word, they write in Scrivener, which is essentially an IDE for prose. Then they export to Word and use this as a common interchange format with everyone down the line in the publishing workflow. It is a very fancy tool.
And really I dunno if NeoVim counts as not "fancy", the first highlight on its page is a section about how extensible it is. It's got two languages to write plugins in, with several screens to scroll down in the list of "plugins and applications that leverage the Neovim API". That is some fancy-ass shit right there.
I've struggled with the notetaking issue as well and think the important part isn't the taking notes, but the processes around it. The paper/ink based note systems that work possibly do so because they accidentally force you to refer back to things repeatedly, like the virtual note taking system they use.
I can certainly think of times I've written and then forgotten notes in ink.
Couldn't agree more.
I keep a notes vim open in i3's scratchpad. Mod+minus and it appears front and center, I make a note. I shortcut again and it's gone. I use one giant text file so everything is always searchable on hand.
I never kept notes before this setup, no matter how hard I tried. I just made it as ridiculously easy and zero-brain-required as possible. I don't even like using vim, but the setup is just too straightforward. I've become a note making machine, and I love it.
It functions mostly as a Todo, so if I'm in the middle of one thing and think of another thing that I want to come back to later, I can add it here. And when I'm thinking, what next? I can consult it and tick things off to feel like I'm making progress and remind me to break big tasks into smaller tasks.
As yet incomplete parts of the process are stealing some ideas from Bullet Journal and having global "pages" that I can call up, a system for copying (not moving!) issues to other places (similar to the > in bullet journals). My theory is that digital workflows err on the side of only showing you what's relevant, and you need to correct for that to a degree to see the full benefit.
I do still like "thinking" with a pen and paper though, not sure why, but then distilling that down into typed text.
> “I’m not writing it down to remember it later, I’m writing it down to remember it now.” The friction of having to write, to structure thoughts in plain text, to remember the name of the person I need to reference on this page: that is the point.
How about writing to forget it? For me, the point, more often than not, is to not have to remember what I am writing down. And if need be, come back to it later.
Those who do not understand this tend to stick people into two buckets and then start an unending argument streak. Recognize that going back is 100% foolproof by definition - hindsight is perfect and going forward is a toss-up. If you can evaluate and have a good measure for current vs. old, don't be afraid to leap backwards. Startups should exploit hindsight and they do.
There are also stagnant local optima that we need to really go out there to find a new peak. These we coin as revolutionary technologies that change history forever.
Love it!
At 61 I am a grandpa, prefer GNU Emacs over vi, but still have fond memories of using vi on 4.2BSD systems. Long time ago!
I think that there are more of us than we think its just that there are no commercial interests promoting our way of working, so we feel slightly unusual when in fact we are just doing the logical thing.
Emacs was cool too, but I never got hooked - was very comfortable in vi land as it was the first editor I used on the old time terminals (green/amber CRT and a keyboard you could kill with). Oh the power of vi/EMACs and regular expressions without ever lifting a finger from the keyboard!
Good times....
This is absolutely... not the case.
Sure, for some kinds of projects Github Issues might do, but for anything "real" Github's issue and project management is a serious regression.
---
These tools are not replacing anything, but addressing broader and broader markets. They lower the barrier to entry and bring more people into the fold (perhaps at the expense at having a lower ceiling of functionality).
There are some attempts but basically at the end of the day it'll require more support from the various operating systems (mainly mobile). There needs to be some underlying open data format which can be synced easily that recreates a database locally that apps can query directly and optionally some way to proxy those requests to a central service when the device can't/shouldn't have direct access to that database (lack of storage, lack of compute to run the database or app, lack of privilege's to have possible direct access all of the data.)
If you can't solve encryption, syncing, and ability to easily use the same rich data between devices and operating systems you won't reverse the trends to move everything to these fancy tools which almost all end up being centralized and requiring the user to be online regularly even for data which only their own devices would ever be using.
So I always think it's good to have a low barrier for people to get in.
Another way to look at it is how we got to simple tools to beginwith: tech-driven industry disruptions. A wave of sw replacement came for tools that are mobile-friendly and support collaboration, like Google docs & spreadsheets, and Figma. Mobile & live collaboration are so important that feature-poor versions of older tools ate giant market share from Microsoft Office, which is 15% of Microsoft's revenue, and the same at Adobe and others.
But Office, Adobe, and friends built up all those features for market-driven competitive reasons. Startups in new spaces get head starts of 2-3 years in consumer, and then maybe a couple more if b2b, but that's it. It doesn't last forever: capital is a moat, and part of that is by building a feature factory, which massive companies like to do. MS and Adobe went SaaS and mobile a few years ago, and they're actively competing here now.
No-one switched from VS to TextMate or Sublime except the author. There’s virtually no overlap in workflows.
I can absolutely believe people switched from either to VSC, as they are designed for similar workflows.
As an industry matures, what users want to do is better known and methods for doing are developed, so a coarse-grained mapping becomes possible - on both ends.
But this process can cross industries above, obsoleting entire roles; and below, creating new roles.
A "role" is something requiring complex user input to specify a result.
I don’t understand why either. Does fade-in make a webpage more aesthetically pleasing? Or serve a functional purpose like improving readability or increasing conversion? To me it distracts from understanding the content and can even lead to janky rendering when implemented poorly.
1. Someone does new thing, it looks stupid,
2. Others realise that even though it may look stupid, it looks new, so they copy it,
3. It's copied to the extent that if you don't do it, you look dated,
4. The stragglers do the thing too, and now it's not cool any more.
We're at stage 3 now with fade-in scrolling. When Wikipedia does it we'll be at stage 4 and then it will be cool to do whatever Wikipedia were doing 10 years ago.
1. cmd+f 'linear'
2. see result
3. smile
I moved away from Windows entirely, and switched to Sublime Text in combination with Unix-style tools (lldb, clang-format). Quickly jumping around in files and searching within the project is fantastic, and the editor is supremely responsive. I have since switched to Visual Studio Code, which is slightly slower than Sublime Text but still fast and responsive.
Well, I, for one, used to use Eclipse and moved to Sublime. It also has to do with changing dev languages and trends over a period. 2005 might have been all about J2EE, 2015 was all about Node, etc.
Do people really migrate or is this more about growth in a user-base? A higher rate of growth of one user-base relative to another user-base is not strictly due to people migrating (as if it's zerosum) but could be due to a tool capturing more new users, like junior developers and such. How often do people really migrate wrt tools they actually use for work?
Personally I still use vi/vim for just about everything and use language specific IDEs for anything only tackled occasionally (I'm product manager not a developer) because IDEs reduce friction and increase my productivity. Recently started using Thonny as python IDE not because I'm a noob (20 years python coding) but it makes jumping into python code ad hoc effortless compared to pycharm or others. YMMV
I've personally gone back and forth over the years between IDEs and decent editors for programming in C, C++, and Java.
I started programming before there were IDEs, so perhaps that has some influence, but you did say "...stopped using IDEs once they started".
I like some functionality of IDEs, but most are barely "nice to have", not "must have" -- the thing I find that I miss the most is language aware navigation.
The thing that keeps bringing me back to just using a reasonably powerful editor (for me, that means either Vim or VSCode, both with zero or very, very few extensions) is the lag between new features coming to existing languages (and new languages emerging) and IDEs supporting them in a non-disruptive manner (never mind fully).
With a decent editor, web or manpage based docs, and a command line based build (which I want anyway for releases and/or CI), I'm all good, thanks.
I mean, if I were to be working someplace that required or depended upon an IDE, I'm not necessarily averse to using one again, but that might be a red flag for me regarding that workplace.
I certainly get the appeal of IDEs, and understand that some find more value in a powerful IDE than in using the latest language features.
Both ways of working are reasonable, depending upon your situation, goals and preferences -- I wish more folks would understand that.
I tried the whole vim thing and no don’t like farting around with things like pathogen and remembering keys. I love a good graphicalIDE too much! I spend most of my time typing or using one of 4 keyboard shortcuts. Mouse is fine for everything else frankly. The mouse is actually a decent invention!
VSCode for web. VS is great for c# projects. I use IntelliJ sometimes and it seems good but don’t use it too much as I don’t Java much.
I don’t think there is a pendulum at all, just a whole bunch of individual coders and teams choosing what makes sense and let’s face it, sometimes, what is hot/cool/hipster
You make a great point regarding reconstruction of IDE's piece-wise. Check out all the "10, 15, 20" VS code plugins you MUST HAVE blog posts. I don't see any difference between that and a tricked out Vim setup. I see them as exactly the same things.
So someone leaving a tweaked out vim for a tweaked out VS Code or vice versa isn't the same as someone leaving an all powerful IDE. Those people are pursuing their perfect bespoke dev experience.
But I stopped, because IDEs were too slow to adapt to current tech.
Text based tools can simply move faster.
Uhh... pretty sure 99% of all complex JVM applications were written using an IDE.
In fact, if you joined an experienced team at a senior level and weren’t using IntelliJ, you’d be laughed out of there pretty quickly...
I find it hard to think I'd give PyCharm up for my daily Python and Typescript.
https://mw19.mwconf.org/glami/smithsonian-national-museum-of...
As recently as a couple years ago I had colleagues still using Dreamweaver to code up email templates (email is the Land Before Time of HTML rendering where tables still rule for layout).
Dreamweaver started at Macromedia too, as did Flash and Cold Fusion. It’s amazing the impact Macromedia had. The founders later went on to start Brightcove, one of the first big white label cloud video providers.
I skipped Dreamweaver entirely and went to straight text editors.
Nowadays on the frontend you can more or less recreate the same effect with Webpack hot reloading. You get instant feedback on changes which makes for a supremely productive development experience.
Slice up those PSDs and, WOW I can try coding it up myself and it kinda-sort looks-works the same as PS!
It was the exact tool Photoshop using website designers needed to up-skill smoothly.
But if I were still working there I would probably replace most of the sites - which were largely abstractions of forms and tables - with something like power apps instead.
Some people don't realise that this is a goal, or that it's even possible.
At Microsoft, this was the philosophy behind the .NET Framework standard library. It is simple, beautiful, and abstracts away reams of complex boilerplate that was necessary with C++ programming.
Now?
I'm using Azure, and... oh... my god. Every internal piece of wiring is exposed, raw, to the end-user. Wear insulating gloves.
You need to know their internal project code names! The undocumented ones are typically the most important.
You need to pass secrets between two agents running on the same VM through your workstation during deployment!
Need to pass an identity around? It's broken up into individual fields, one of which can only have a single valid value. But you have to provide it using a programmatic lookup.
Want Accelerated Networking? There's a convenient Boolean flag for it. Great. Except that it'll break deployments if the VM size you've selected doesn't support it. How do you know if a VM size supports it? Bahaha... you don't. Build a switch statement with 300 entries yourself. That's what the Indian subcontractors writing the rest of Azure's code do! It's good enough for them, so it should be good enough for you. (I wish I was kidding, but I have seen the code and it is literally this.)
Ultra Disks? Switch statement.
Availability Zones? Switch statement.
You get the idea...
I have spoken with several Azure team leads, and they just blink at me slowly with an utter lack of comprehension when I explain that this is just not good enough. That in Visual Studio, I can tab-complete a type and it will compile. That 100% certainty is not comparable to 90% certainty in Azure, where a boolean true value might need to be the string "true" value because fuck you.
I fully agree with the experience, add on top of that CLI tools for what used to be VS wizards, code instead of GUI designers, killing C++/CX replaced by C++/WinRT, which after 4 years still doesn't have VS tooling support, 5 competing GUI frameworks on Windows,....
Culture reboot at Microsoft went a bit too far in the wrong direction.
I'm stealing this one. Hope you don't mind.
Important to note that the subcontract would be paid 1/10th of what his counterpart in Silicon Valley would be getting.
Which I feel a lot of modern software struggles to provide. Sure I can onboard quickly and do _something_ but if I'm spending hundreds of hours I want to get better at it and improve my returns.
We did a comparison program with a sister city who uses Jira for their entire process because it had been a good time-tracking system at the time, and we found that their project managers and developers spend around 5 hours a week on something that ours spend on average 35 minutes on. This is anecdotal and we’re not exactly real “software development” cases as we are small helper functions in major enter organisations, but it does speak volumes as to why using Jira in our little anecdotal setting seems terrible. This doesn’t mean our sister city will change their ways though, they won’t. So in a sense you’re right that jira isn’t getting replaced at their place, but it does mean we won’t consider it and will instead look to other tools.
Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting.
What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.
There are boards, but they are so unwieldy. Just put all the work items on a board and let me drag them around and see everything at a glance.
Everything else with the source control and build pipelines and wikis is so good, this weakness is glaring.
No idea what the best option is, any recommendations for tools developers will actually use or do you just need to do a custom integration with github issues?
A few additional things would be required to make this work for less-technical team members, and you end up building some of your own workflow, but it means that E.G. you have options like "update the description of a ticket as part of the pull request that implements it".
- Very seriously discussed prototyping a remote robotically operated version of a real physical board with a friend when the pandemic started, but we both got too busy.
- Trello, with most optional things not turned on, is still the closest thing to a real kanban board. Do go ahead and enable GH integration, but don’t turn on the zillion things that turn it into yet another Jira.
- AirTable’s kanban view is surprisingly good, but it’s fundamentally a shared spreadsheet and a lot of UI/UX confusion comes from that because any filtering or sorting you do is global to others using the same view.
The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
The real problem is that it gets over-customized, and as with all databases, schema is forever, so after enough years of using it you have: ugly remnants of how you used to do things mixed with the ugly new things you're doing, and a devops team dedicated to maintaining and further over-over-customizing your JIRA instance.
I personally hold the view that it could have been better and that a more general notion of persistent object (not in the OOP sense) would've been better from a user facing pov.
The filesystem is doing more than one job, holding multiple responsibilities and imposing a way to present data and how to store it.
Users would much rather work with logical items. A "photo" which includes metadata, photo files, photo edits, ratings, face/object detections, and etc. as a single "thing". A tweet thread. A blog post on Medium or in WordPress. A Google Doc or Sheet.
The question is how do you provide that seamless "anywhere, anytime" experience while keeping that data as local to the device as possible? Files by themselves just can't solve that. There needs to be a protocol, a data format, and mobile OS support.
(apart from that: a filesystem is nothing else than a database, and text files are pretty much the most open data format imaginable, it's not like we arrived there by accident).
But generally IDEs are almost a necessity for any complex Java codebase. That's markedly different in other languages. I sometimes work on the chromium codebase (C++ mostly) which I use either VSCode or a simple text editor for. When dealing with smaller scripts, whether in Python, Perl or Bash or whatever, I usually stick to whichever simple editor I happen to have accessible. The same is true for some small C codebases I maintain on an irregular basis.
Generally I consider it a rule of thumb that the more refactoring a codebase requires to be kept in a maintainable state, the more you profit from an IDE. And the necessity for complex refactoring grows with the size of the codebase and the number of developers working on it (especially if a lot of them happen to be rather new to the craft).
I mostly started with Java in various IDEs. Now I'm using Vim whenever I can, as it's pretty much the only powerful editor that doesn't work against me. IntelliJ is incredibly annoying, e.g. auto-formatting the line I'm still typing, turning my inputs into undefined behaviour. Or telling me a file contains an error but not showing an indicator in which line (of >1000) that error is. But I sure am glad it displays 50 markers on the sidebar to tell me the location of every word in a comment the spellchecker didn't recognise. And to top it all off it switches tabs in some random order instead of the order that's literally displayed on the screen (I don't know why this trend is a thing, I'm not too dumb to rearrange my tabs, thank you very much).
No, Vim isn't perfect. But it's snappy, reliable and most importantly doesn't try to "help" me without asking.
There was also the open-source alternative, OpenDoc[2] that never got anywhere... this has been tried and just doesn't work.
The only thing that seems to work is media-types on the Internet... with the browser as the universal viewer/processor... but as it is currently, it's hard to make it better than what we have.
[1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
Power Apps is good but not great.
Why haven't we seen a true successor?
Microsoft should do a native TypeScriptVB or something.
Is there a more sophisticated Python tool than PyCharm?
My biggest gripe is the Mypy type-checking which only discovers errors minutes later.
* Advanced Roadmapping - JIRA will, given a pile of issues, sort them and fake-assign them to individuals on your team to determine how long it will take you to complete a project. This is way more powerful than burndown charts and cycles when you're planning a hardware project with a tightly-defined deadline. Without it I have to drop back to spreadsheets to provide any insight into when a project will be completed. It's especially important when the business peels engineers off the project.
* Time-based estimating - JIRA lets me plug hours in for estimates instead of railroading me into T-shirt sizes, which means I can actually use the tool to give an accurate estimate of when we'll be done. Linear requires you to calibrate your expectations by running a few cycles first, which makes it a really bad fit for projects that have a defined end date.
I think Linear has a lot of potential for teams that don't work to fixed deadlines, but for my purposes it's just a very fast spreadsheet.
I'll check out Linear. Been looking at Clubhouse too.
Very DIY. You can build great workflows if you put the effort in. Brilliant reporting, main reason we adopted.
Clubhouse for example gives the agile structure (epics, stories etc) by default and you conform to it. Minimal setup effort. From a 'management' perspective I actually like monday, by the actual end users don't seem to like it.
Getting a true hierarchy and relationships requires similar thought to setting up a SQL DB. Powerful, but I don't think we have the resource to really build upon and support stuff.
* Some of them make a mess of some part of git; one of them put its info in separate git branches you couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.
* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.
* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.
* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.
Sibling mentions git-bug, a few others I recalled/quickly found:
https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)
https://github.com/dspinellis/git-issue
https://github.com/neithernut/git-dit
https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)
To me this is the main point of storing issues in git!
In any case, I believe that it's better to build a data model/storage without that concept (read: don't store the data in the same branch as the code) to have the freedom to built it with less constraint and make it right. Once that work you can add this "branch sensitivity" concept on top and again make it exactly how you want it.
An example of problem you get when storing the bug data in normal code branch: cool, you got the bugs state deeply stick with the code so you know exactly when a bug is resolved and in which branch. But now you are stuck with git only to deal with merge conflict, which means you might need to have the user fix it when it goes wrong. Will you push that to a non-technical person as well? Also, what happen when you rebase or cherry-pick?
(I'm in a many-repo company that used to use the per-repo bugtracker built into Bitbucket and switched many years to Jira. Jira has its warts, but it's miles better for the project management level task of burning down to a release.)
It's a losing battle between tool functionality and reporting abilities.
The pull force in JIRA is how much it gives PM's and other managers a feeling of air traffic control visbility. It ends up serving as a medium for less technical people to digest and participate in a project.
The features that in my opinion keep Atlassian profitable is all the automatic reports and analytics features more so than the daily work functionality.
The problem is that JIRA is a powerful tool that is often misconfigured or otherwise made to suck more than it should.
For example on one of my current projects, both JIRA and confluence are put behind malfunctioning SSO meaning you have extra annoying steps that sap your energy and will every time you open them. And then you have to face that someone made a royal mess in it and we have to deal with it - without access to settings to fix IT. And the final nail is that effectively we can't use any external integration, because it's all blocked, including just using the API on your own.
Now, if I had the power of administrator there...
We would have better work flow, with automation supporting human overrides.
We could link issues with our Github Enterprise and use local clients (org-jira, gojira, etc) as well as a bit integration in MS Teams.
And I would fix login so that accessing JIRA or Confluence didn't feel me with annoyance of "where is that fucking RSAID" and "goddamn fix MFA already"
However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.
We tried dozens and I've put it down as an unsolved problem.
That's not my experience of Jira. The cloud version is the best, and our current on-prem installation is perfectly fine. I agree that Jira isn't the snappiest tool to use, but I don't sit there consciously waiting for it to do stuff.
For example, I just tested following a permalink to a comment on a ticket. After 1.3 seconds I see the ticket - but it takes more than 7 seconds until I'm scrolled to the right comment, all the ticket details are loaded, and so on.
And the slow-ass lazy loading means you daren't click something between 1.3 seconds and 7 seconds, because at any moment a new button or linked issue box or the addition of status icons next to links or something will reflow the page.
In my experience this shitty performance is baked into every single interaction with Jira. You want to create an issue? Two seconds to show up the form. You click the 'epic link' dropdown on that form? A full second just to display a dropdown menu. Oh, and you also want to open the 'label' dropdown? That'll be 1.8 seconds.
And all those are on Cloud Jira, at a weekend, on a <300 ticket project, on a powerful developer workstation.
It is forbidden in the ToS 3.3 to “(i) publicly disseminate information regarding the performance of the Cloud Products“.
They might as well say it:
Will be slow, we feel that does not impact the value proposition.
Our license revenue is super necessary and this is not a race.
Ya, slow now because we need users and features now, go faster later.
If you need it to be more performant, pay us more and make the hardware investments we tell you to...
I personally would respect those more than a blanket gag attempt.
100% of the time I want Jira to do stuff is when I'm interacting with it, and thus absolutely waiting for it.
It just gets in the way. Individual actions are tolerable-ish. But it’s never setup right. Constantly hunting for the field that is blocking story creation. Permission issues all over the place.
Finding things is often nightmarish.
Management basically doesn’t care, and doesn’t want to put effort into making it work in sane fashion. Yet freak out if team wants to use something else. So we do all our planning and story tracking in google sheets instead.
Fast solutions clearly exist. But somehow everybody ends up using slow Jira.
You are right that it's difficult to replace the entire Atlassian suite. The thing about Atlassian is that when there's if there's a box to check on a feature list, they've made sure to check it. If you go around the office asking everyone what features they want, Atlassian is going to check all those boxes. That's pretty hard to compete with.
I kind of want a modern version of Trac. Trac is essentially a collection of integrations that just happen to have useful features.
There's no "coherency" to them.
Take for example the admin UI. When adding "Application Links" to link Jira and Confluence with each other, Jira has a nice tabbed interface allowing you to configure it easily, whereas in Confluence, you have to scroll down a long sidebar with dozens of options until you chance upon the required link. Had similar experiences configuring various other options at the filesystem level.
Jira configuration was more coherent, fault tolerant and failed gracefully. Confluence configuration on the other hand was messy in comparison.
Isn't Phabricator trying to do all of this? It seems to get quite a lot of fairly high-profile usage in both enterprise and community-focused/FLOSS contexts.
It's just those two though, it's also the git branches, pipelines, and release integration from jira, being able to see the support ticket cases and / or alerts that were the cause of ticket/branch/release.
I'm in no way arguing that atlassian does a great job here, only that no one else offers that end to end integration. (Possible exception of phabricator mentioned in a sister thread)
That would be one legit reason for thinking about writing this clause. Because it’s really curious to think about writing that.
Whoever thought it was a good idea to build a CI tool on a concept of information hiding is a monster who should be banished back to whatever eldritch plane they crawled out of.
You can’t have a coherent conversation with anyone about the functionality of Bamboo versus other CI tools because Bamboo is constantly lying to you about what is available. You don’t even know to ask other people for help with something because you don’t know if Bamboo can do it. So people use the ugliest kludges that their privilege level allows to get things done, creating an unmaintainable mess in the process.
Compounding this issue is how many clicks even "simple" tasks take because of their bizarre choices. Basic necessities like changing ticket status can't be done without opening separate pages, etc.
One you've actually managed to create a ticket and assign status, good luck finding it later. Backlogs inevitably evolve into infinite swamps that no one knows the full contents of. Not helping is the fact that the search is terrible. I often vaguely recollect some detail or test procedure that someone helpfully mentioned/documented in a ticket somewhere before closing. I successfully find maybe a third or less of those.
Also it's highly customizable, so any skills or knowledge from one company don't apply to the installation at any other.
> A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful
I use Jira daily, it's nowhere near this bad. It's not fast, but pages load in about 5 seconds.
> changing ticket status can't be done without opening separate pages
You select the new state from the drop-down and set it. This is available through a few different routes/views.
> good luck finding it later
Their search looks through title and description, what else do you want?
> Backlogs inevitably evolve into infinite swamps that no one knows the full contents of.
If you let them, of course. If you don't close the tickets, what did you expect to happen?
Edit: I did have the bad luck to discover it performs pretty horribly if you’re on a high-latency connection to the office. I think it makes a lot of round-trip requests.
Properly configured on-premise installations are usually quite fast.
> I think it makes a lot of round-trip requests.
It does, and that's the main issue
I’ve seen both good and bad Jira configurations. And I’ve seen them run on both good and bad hardware solutions.
There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly.
I submit that anyone who hates Jira probably has not seen a good Jira configuration. And anyone who loves Jira probably has seen a good configuration and doesn’t understand what everyone else is complaining about.
Jira is a real Jekyll vs. Hyde type of tool. In my experience, how you feel about Jira says much more about the type of configuration you’ve seen than anything else.
This has been done wrong by Atlassian.
I’m sometimes really jealous when I see fast self hosted public JIRAs and by the meantime, the instance I have to work everyday on atlassian cloud is both snail-slow and airplane-heavy.
And they are replacing it with JIRA Cloud that cannot be configured at all, and is unbearably slow.
I am not normally a "less features is more" kind of person. But with issue tracking, I am.
I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance.
Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle.
My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello.
The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.
In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.
FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.
I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.
I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together.
I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it.
The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced).
Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it.
If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.
It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.
I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth.
Since last using Jira I've never felt nearly as aware of the state of a project as when I did.
The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals.
The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track.
Management never spotted.
So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks.
I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.
Has the "Sprint" link always been on the bottom of the rightmost column?
Then your managers would buy a tool that did instead.
> maybe just try not to smush existing ms CRM workflows into a tool for devs.
If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get.
Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.
A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.
The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value.
But, in either case, not having that realization is management issue, not a tool vendor issue.