My consistent observation over 30 years experience has been that there are alawys three methodologies in effect:
1. The paper methodology that everybody completely ignores - this is Scrum or waterfall or rational or whatever they call it
2. The management ideology that management actually insists on and bases your pay on - the ticketing system (nowadays it's JIRA, but there's always been something similar). In theory it's driven by the paper methodology but in practice it's somewhat random.
3. The support methodology that everybody follows - drop everything and work on this emergency because Somebody Important mentioned it. This is what your reputation is built around, and is always independent of the other two methodologies.
In my company at the time, they had a million rules and processes, but everybody had to drop everything because the son of an influential client could not get toy cars (!) into the new enterprise retail procurement system because of some incorrect logistical data. Normally you would get a ticket, analyze etc.
But he was the loudest/most influential, so everything else was unimportant. No Jira, nothing, just one angry email. Fix it for him alone, NOW! Billion-dollar company, thousands of clients but a dude with 20 toy cars won.
The issue was resolved (we removed the validation rules that were implemented before because "this is the filter for incorrect data, and we want to clear our data by restricting them") and everything went back to normal. Jiras, process and so on.
One of the reasons why I would just open a Jira ticket anyway, process be damned. If I’m suspending work on a P1 because of this ticket, I’m gonna mark this ticket at least a P1. If management wants me to complete it within X hours, then I can find the priority level that matches the X-hour turnaround time.
I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours). I don't see why. It's really not that hard in most places to create one. Even in large and bureaucratic ones.
I always found that tickets are protection. When you're being asked to "drop everything for X", my first thought is to create a ticket for my own protection. At the least I can track the fact that I had to spend N hours on this thing X and I can refer back to it. At best I can document the stupidity of the whole thing w/ the ticket contents.
If you're in a place like my sibling where they ban creating a ticket yourself and assigning yourself: run. That's so stupid for so many reason that it's not even funny any longer
"I have found that many many developers are averse to tickets and complain about having to create tickets (like we see in a sibling of yours)."
I can give you my answer: Because the ticketing system is painfully slow to log in to, create the ticket, move it to the proper status, etc. Single sign on can make things worse too. The whole process can add up to easily a minute, and not a productive minute of the actual filing (I would be fine with that) but a minute of poking at things.
This does not make you wrong. If you want to say there's some laziness there, yeah, maybe. But it's not just laziness, there's a psychological torture aspect to it all too that is, if not "objectively" true, then at least not entirely my imagination either.
I really, really, really wish Atlassian would basically drop everything for a quarter or two and work on the speed of their products. There shouldn't be a fundamental reason why their stuff is so slow.
Not to say your experience isn't awful but have you actually timed this? (also Cloud vs. Server can make a huge difference - Cloud being faster even if their recent UI changes aren't all great).
Login processes can suck. Absolutely. But like you say, single sign-on means you should at max be logging in once per day if not even less.
So just for giggles I timed various things in our instance for you. I have a logged in single sign-on session already.
Opening the Jira instance to my default dashboard until I could conceivably click on the "Create" button: 3.5s
Click the "Create" button until I could start typing into the summary field (while the rest still loads): 1.1s
Now as for filling out what you need, that obviously depends on your company and they can make it a pain, agreed. If we're talking about the "someone tells you drop everything now and to work on X" I doubt it takes more than 30 seconds to fill in even one of the "wild" issue creation screens. I mean you literally have to type something like "Exec B made me work on X" into both the summary and the description field, maybe choose an issue type and select the first value of any dropdown required fields and type "a" into any required input fields.
Actual ticket creation duration shouldn't take much longer either and even if, who cares? By that time I'm already back in my IDE.
I'm not who you're asking, but I have timed this at multiple workplaces. The most egregious example took 32 minutes end-to-end (for many reasons: Jira was behind a VPN, which was extremely slow to login and even slower to actually use, the SSO system only allowed a session to persist for an hour, the server actually running Jira was underspec'd, the ticket template was incredibly verbose, etc, etc, etc). I am excluding the time it took to type the ticket in the first place (I wrote up the text beforehand and copy/pasted it into the fields) and including the time it takes to sign in to SSO, log into the VPN, browse to the ticketing system, etc. Essentially, I assume that it's the start of a work day and the only thing I've done is boot up my machine. Excluding the 32-minute workplace, I've got an average of ~9.5 minutes (only one was < 60 seconds).
While many workplaces have good systems, don't assume that every workplace does. There are many out there who accept/mandate potato-quality tools.
Hehe fair enough for your case. Yes, those absolutely exist. If you're not working for a military contractor or something there I hope you ran a long time ago. This seems to indicate that a lot of other things would be wrong with that place too.
I asked my parent if he timed it, because he mentioned "a minute". Lots of things feel longer to us than they actually are. If you're waiting for something to open or react to a click or other input even half a second can feel long and we're bound to say things like "whoa that took like 30 seconds, WTF!". But when you time it, it actually takes way less.
E.g. opening an issue directly from a new tab in Jira takes about 5 seconds for me in my quick test for example. Yes, that's absolutely a "long" time for what it ultimately needs to display and do. But it's also nowhere near a minute and if all you gotta do is to open a ticket someone sent you because you're supposed to "work on ASAP", these 5 seconds don't matter. You'll wait about the same time to run your unit tests after making the required change. You'll wait way longer to run the entire test suite etc.
We use cloud Jira, without any sort of crazy customization. This morning, I wanted to unsubscribe from a ticket.
It took about 15 seconds to load the ticket page, and another 5 seconds to process the unsubscribe. I just tried again now, and it took "just" 3 or so seconds to load the ticket page.
Their p50 time is already unacceptable, and their p90 time is completely absurd.
We've known what acceptable delays are since 1968[1]! Why is it so hard to build software that meets these requirements? Our computers are only 20 million times faster than back then...
Try Linear[1] and let me know if you have ideas how to sell speed to program management or execs. Startups get it, it’s more rare that large companies see the value.
The worse is maybe not the total time in itself but the lag effect.
It is annoying to click on something and wait 4-10s for the page/board to load or the login redirect dance to be completed.
So, what happens is that you click, and you go to do something else like reading another page in the meantime.
And then you completely forgot what you were about to do and when you remember you are already logged out or you have to refresh the board again, and it is slow again, so you go do something else in the meantime, etc...
And so on you lose a lot of time with frustration.
I think many developers have a vague understanding of how companies work and how their role fits into the company at large. I know a lot of developers who want to focus only on solving technical problems, want to be given the freedom to make technical problems, and want to have the other problems solved by everyone else.
If you’re focusing on technical problems, a ticketing system is a burden imposed on you by management. If your priority is the success of your entire team rather than the success of your own technical decisions, then you’d understand that visibility of your work, your thought process, how you justify decisions, is all critical knowledge that a ticketing system serves to record and disseminate.
I can’t count the number of times where I found a reference to a bug in a piece of code like:
// Release gadget early to avoid starving froopy pipeline,
// see bug #12345.
And the ticket turned out to be super damn enlightening. You get to go back in time and relive, vicariously, a debugging session from two years ago by a team member who left the team.
> want to have the other problems solved by everyone else
In other words, do their job and not do everybody else's job for them? Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
Are you trying to make a point? Could you make the point directly, rather than make some vague, sarcastic comment?
If I’m interpreting your comment correctly, there’s a lot wrong with what you’re saying. First, the “job” that computer programmers do is much more than just writing code and designing systems. Computer programmers are expected to prioritize work, advocate for work that they think is important, gather requirements from stakeholders, make decisions about who holds various responsibilities, document and communicate the process to team members, and disseminate knowledge about how systems work to others. Just for starters.
Second,
> Or conversely, get paid everybody else's salary since we're already doing all of their jobs?
1. Computer programmers are paid generously, at least where I live. One of the reasons we are paid generously is because computer programmers are very efficient at getting work done that may otherwise need many people.
2. It’s not somebody else’s job to follow you around and document what you’re doing and justify it. It never was. It was always your job.
“Keep your head down and just do good work” is a kind of hyper-individualistic fantasy. It’s the fantasy where you’re some kind of powerhouse getting work done in your own world, and you do not need to advocate for what you feel is important. That’s what I’m arguing against. The technical part of our jobs is only one part of it, and you can’t make a good team out of several highly skilled programmers if they only have technical skills.
And then there was the place that (when I started) used Remedy. (Ever seen the ticket creation process there? Of course, only customer-facing people were supposed to create them.) That wasn't good enough, so they added a customized Jira for the devs to track their activities. (A Jira ticket had to be associated with a Remedy ticket, even for new development.) And finally, they slathered on a layer of Rally on top to make sure we were suitably Agile.
That's I guess where the "most" comes in ;) Yes unfortunately I have seen other systems than Jira and most are awful. That's another thing developers complain about a lot: Jira. I find Jira is a breath of fresh air compared to traditional systems and fortunately in most places devs only deal w/ Jira like in the case you described.
Were you unlucky enough that they actually had checks in place or was it the typical "these systems are 'integrated' but not really"? If no checks, then to hell with the remedy ticket. I'm not putting any. If it only checks for not-empty field, I'll fill in junk. If they do check existence, I'll find an unlucky Remedy ticket that gets stuck with all my Jira tickets. If they check that the Remedy ticket is actually still open, I'll somehow find one of those Remedy tickets that are forgotten and hopefully will never be found and cleaned up (unlikely anyway) and that one gets stuck with all my Jira tickets. If only one Jira ticket can get associated with each Remedy ticket (which is again stupid for so many reasons ...) I'll use subtasks on one special "junkyard" Jira ticket.
I'm sure there are more cases you can think of and where we can find workarounds that still allow me to publicly document what I worked on.
When I have aversion to creating a ticket, it's around the weight of the ticket to create.
What I generally want is someplace to cheaply mark an action item to create a ticket, so I can jot down a quick idea, then come back to write the heavy weight ticket from that later.
If I'm aiming to jot something down, it's because im focused on a work item, and don't want to fully context switch away from that item and into the user story and background details for the new ticket. It's not that it's hard to write the ticket, but it's hard to resume the work you were doing before you were prompted to open a ticket
> I have found that many many developers are averse to tickets and complain about having to create tickets
FWIW: I've consulted at places in the past where developers couldn't create tickets, only update them. It was most definitely a way to attempt to keep them under control and harder to advocate for themselves.
Ideal process IMO is that developers should casually drop some lines in the chat like "we need to refactor ScaryService some day. Some manager carefully reads that chat and creates ticket in the backlog with link to the conversation. There's friction and there're people who supposed to support processes and can ease this friction.
I usually do. I once worked for one company that was so dysfunctional that they implemented a rule that made it impossible to open a ticket and assign it to yourself to prohibit that.
Then in your retro meeting the manager/TPM/etc. talks about how we need a better process which results in nothing changing apart from more tickets to create.
And I think #2 and #3 is why #1 is true. Or put differently, my experience in changing processes in many places has convinced me that unspoken management dynamics are what really matter, and that most managers will resent any process change that makes the actual management dynamics obvious.
For example, one way to classify process changes is when they make problems obvious. E.g., a release-early, release-often approach makes problems visible early on. And I've had great luck with them on teams that are actually trying to succeed, because faster feedback means faster learning. But most organizations reject that because actual success doesn't matter nearly as much as managerial appearance of success. Many managers thus hate fast-feedback processes because they would rather hide negative information, even if that makes long-term success much less likely. But they like the appearance of success that comes with using the latest buzzwords. This results in the common pattern of the manager who talks Agile but whose projects are in effect waterfall.
In many enterprise software markets, customers legitimately hate frequent releases. Each new release may force them to retrain employees, do their own compatibility testing with third-party systems, and possibly even go through some sort of expensive legal compliance process. It's a good discipline to always keep the main repo branch in a fully releasable state, but only push out actual releases on a slower schedule.
I agree that for certain legacy markets that's the case, but I don't think that's the future of software. One of the things that distinguishes enterprise software is how little the users or their experience matter to making a sale. Those also strike me as defensive choices. Defending against bugs, against bad relationships, against bad design.
All of those are true for some markets, but it's no way to create new products because it breaks core feedback loops. Companies that don't have a way to improve will eventually get replaced by those that do. And as you say, they might then become the next company forced to slow their pace by their customers. But I am hopeful that even enterprise companies will learn to move faster.
It depends what you release. A bug fix, an extra plugin etc. is not going to disrupt the user as much ad a UI overhaul.
Feature flags and great communication with customers and empathy means you can have frequent releases without annoying the customer.
It should be strictly better than slow releases. You can emulate a quarterly release of 1000 changes at once if you want that. Or you could say release fixes and small feature
continuously and big features are timed with the customer/training/support functions. They might even be beta/optin at first.
Getting the code out fast always and then providing ways to avoid
dumping confusing features on people seems
better to me.
Development methodologies sort of work -- they don't work perfectly, but nothing really does. Most teams practice some sort of pseudo-version of methodology #1 while they do the practical work of methodology #2.
That doesn't mean methodology #1 is useless. Agile/scrum really did have an impact on the industry, and the proof of that is how hard it is to find people who still advocate for the kind of waterfall methodology that was once accepted by pretty much everyone.
The annoying thing about development methodologies is meeting people who don't understand that the map is not the territory and insist that a perfect application of a methodology is absolutely necessary. They drive everyone else crazy with buzzwords and process. Most people are fine with a sort-of agile process that takes reality and business value into account.
As somebody who was very involved in the Agile movement early on (2000-2008 or so), I don't think Agile deserves the credit here. What I think actually happened was that the rise of the internet made faster release cycles both possible and necessary. Scrum rode that wave, saying that they had the solution. But most Scrum implementations I've seen are not what I'd call conscious, proactive process change. It's just a new set of labels for accelerated versions of the old behaviors (waterfall or code-and-fix or a mix), plus a revenue stream for consultants and a certification scam for everybody else.
I completely agree with this. Yeah, it's not like they don't work at all, it's that they work to some degree.
And, yeah, I think a lot of devs would agree that the traditional waterfall is not as good a process as agile. You could say that it's an antiprocess, whose basic idea is that the old inflexible waterfall with its overly structured teams is inefficient. Yes, small, tight-knit teams working closely together and iterating quickly is much more productive, creative and rewarding way to work.
... although, in my humble opinion, the one thing that agile really needs to stress more (that is key in the waterfall) is requirements. A (couple of) dedicated rounds of requirements where you talk with users (and stakeholders) saves a ton of dev time - agile does have requirements, but at least in my experience, devs seems to gloss over it.
I would also add that management often subverts the methodology by using them as a form of metrics. In my experience with Agile/Scrum they started to expect design and implementation in 2 weeks cycles which is unrealistic for large projects. This ultimately ended up in an inability to execute and complete projects that needed long term thinking and planning.
Number 3 seems about right. My Vulcan brain thinks that something like number 1 must the answer, but my lizard brain knows that the food pellets drop when I follow number 3.
Back in the day, our CEO's neighbor mentioned that our site didn't work well on Microsoft's WebTV. WebTV appeared on our list of supported platforms.
On point 3, also you have a plethora of PMs who are insistent they are important and can bend the will of Somebody Important and definitely aren’t just relaying those “drop everything” requests and are actually a proper job of being a PM…
1. The paper methodology that everybody completely ignores - this is Scrum or waterfall or rational or whatever they call it
2. The management ideology that management actually insists on and bases your pay on - the ticketing system (nowadays it's JIRA, but there's always been something similar). In theory it's driven by the paper methodology but in practice it's somewhat random.
3. The support methodology that everybody follows - drop everything and work on this emergency because Somebody Important mentioned it. This is what your reputation is built around, and is always independent of the other two methodologies.