Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the longest Atlassian outage

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

341–350 of 772 posts

Re: Inside the longest Atlassian outage

#341

Post by aaaaaaaaaaab »

systemvoltage wrote: post #78
throwaway894345 wrote: post #36

Earlier quoted context omitted.

I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to sit down and think critically about the use cases and instead decided it would be easier to say "yes" to every single feature request. It definitely feels like whoever is buying JIRA is not on the team who is using it (maybe IT or finance) because it ticks the…

What's wrong with C++? Seems unfair to compare it with JIRA.

It's a HackerNews meme from people who never bothered to properly learn C++ and are angry that it's not JavaScript/Ruby/Rust/whatever.

Re: Inside the longest Atlassian outage

#342

Post by heisenbit »

treesknees wrote: post #306
rjmunro wrote: post #271

Earlier quoted context omitted.

What's the difference?

Good faith would be to lose all of that money to people who are already your customers. Business-wise would be to stay in their good graces and keep those customers by offering the refund, but you don't lose any money to those who either don't care or won't move to a competitor.

Reducing the impact analysis within a long running relationship to a single transaction is too narrow. People observe how other people are treated and draw their conclusions even if not impacted. People may tolerate some abuse but it moves them closer to leaving next time. Money lost in the outage may provide for a budget creation to look for an alternative.

Re: Inside the longest Atlassian outage

#343

Post by throwaway894345 »

hhmc wrote: post #264
throwaway894345 wrote: post #89

Earlier quoted context omitted.

I was a C++ programmer in a past life and I sorta like it. C++ and JIRA seem to have the same philosophy with respect to choosing which features to admit: "yes". The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. What people frequently fail to realize is that the absence of misfeatures or redundant features…

> The idea is that by supporting the largest number of features possible, they'll surely build something that everyone likes because it will tick everyone's boxes. The idea that the C++ committee are unthinking people pleasers it patently false. C++ does have a lot of cruft, but mostly because it aims to: i) support new features ii) maintain pretty strong backward compatibility guarantees In general the new features…

"unthinking people pleasers" isn't how I would characterize it; rather, I think of it more as a "kitchen sink" or "more is more" philosophy rather than a "less is more" philosophy. I'm sure the committee deliberated extensively, but deliberation within their particular philosophical context still produced an unpleasant result. I think the same is true of JIRA.

EDIT: clarified wording a bit.

Re: Inside the longest Atlassian outage

#344

Post by moonbooth »

grog454 wrote: post #307
a4isms wrote: post #76

Earlier quoted context omitted.

They used to say of Microsoft Word, "Nobody uses more than 5% of its features, but every company uses a different 5%." The saying is apocryphal and unlikely to be accurate, but the shape of the thing its describing applies to almost every piece of enterprise software whether installed on-prem or SaaS. And as another comment points out, at Enterprise scale you can substitute "team" or "group" for customer. Every team…

>"Nobody uses more than 5% of its features, but every company uses a different 5%." >The saying is apocryphal and unlikely to be accurate Well its mathematically impossible to be accurate as soon as you have > 20 users.

Only if you assume the 5% of features to be a contiguous block each time.

However, if we assume there are, say, 100 features in Word (the real number is likely much higher), the number of combinations is orders of magnitude higher than 20.

Re: Inside the longest Atlassian outage

#345

Post by mrits »

function_seven wrote: post #196
mrits wrote: post #96

Earlier quoted context omitted.

I wonder why you use Jira if a spreadsheet is sufficient for your use case.

Same reason I use oil lamps when the power is out, even though electric bulbs are my normal lighting. A spreadsheet may be sufficient, but it's not as good as a system designed for development workflows. (This comment sounds like I have a speck of love for JIRA. I don't! :)

I don't see this as a valid comparison. There is information loss. This has happened to my team which had about 50 people and it was very chaotic. It took us several days to just create the state our features were in.

Today it would even be more troublesome as we have a lot of integration rules dependent upon the workflow. I'd probably just recommend everyone uses a few weeks for self improvement and only address critical production issues.

Re: Inside the longest Atlassian outage

#346

Post by pphysch »

originalvichy wrote: post #221
kgeist wrote: post #142

We use on-premises setups for almost everything (we generally avoid cloud solutions to have full control of our data), sometimes (approximately once a month) it goes down for a few minutes which already feels like a torture because all our processes depend on it, I can't imagine having no access to it for several weeks, all our work would stop to a halt... The office of the guy who administers on-premise servers is l…

I am biased but I can tell you what works best for mid-large companies: having a solution provider. Basically a partner that hosts and maintains the instance and has enough Atlassian certified people to help you with any question so that you will never have to hire people to just maintain the beasts or tell you about features, tricks or plugins that could solve problem X. Experienced people hosting and tuning Atlassi…

It seems like if you are going to pay for a bunch of SaaS seats AND a team of technicians/engineers for make it work, you might as well just do the latter and roll your own solutions...

A lot of these SaaS are just glorified Rails apps with a patina of professional "security" and "reliability", and loads of extra junk that your co will never use.

Re: Inside the longest Atlassian outage

#347

Post by stuff4ben »

Cd00d wrote: post #335
throwaway894345 wrote: post #36

Earlier quoted context omitted.

I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to sit down and think critically about the use cases and instead decided it would be easier to say "yes" to every single feature request. It definitely feels like whoever is buying JIRA is not on the team who is using it (maybe IT or finance) because it ticks the…

Interesting take. Personally, I like JIRA. I think it adds a ton of transparency in our org, and while I've used Trello for personal and home projects, I don't see how it's good enough for business. Trello doesn't even allow for time estimates (last I tried), which for us is part of planning. Search in JIRA is also really good, so no ticket is ever just lost to the ether. Sure, it's not perfect, and waiting for a boa…

GitHub Enterprise and ZenHub Enterprise work well for us here @IBM, not that I speak on behalf of them, just a drone doing work.

Re: Inside the longest Atlassian outage

#348

Post by 52-6F-62 »

codycraven wrote: post #185
closeparen wrote: post #136

Earlier quoted context omitted.

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque : you have no way of knowing whether they're working or not. Another problem you face is that they're uppity : people who went to college and got used to managing their own time now have all kinds of idiosy…

It sounds like you've been hurt by the some terrible management practices, I'm truly sorry that some managers think their job is to control their subordinates. However, regarding ticketing systems, in team environments, it is very effective and helpful to have a system that manages the data about the work that has been completed, is being worked, and is planned to be worked on . Part of that system might be defining…

Kanban, by design, was a tool used in production control. It's one of the ways Toyota made their JIT production function.

I worked on the line (Toyoda Iron Works) and used a real-life Kanban implemented by the plant engineers. It was used for quality control, to broadcast quality control and station output, and was checked regularly against their internal estimates and baselines and used also as a gauge for employee output.

Control is what it's designed to do. The very fact that Kanban is the tool of choice should support at least some of OP's points, objectively.

Re: Inside the longest Atlassian outage

#350

Post by towelrod »

bombcar wrote: post #93
dxf wrote: post #62

Earlier quoted context omitted.

>Are SLAs even real? SLI: Some metric you use to measure a thing (e.g. uptime, latency, etc.) SLO: Some objective you try to hit, as measured by the SLI (e.g. "99.99% of requests are processed within 3 seconds) SLA: A promise to a customer that they will meet some SLO, and consequences if they don't. If there aren't consequences for not meeting the SLO, then measuring and tracking the metrics is a pointless exercise.…

Most SLAs say "if we miss this, you get time for free" which means that these companies will hopefully get a refund ... for the time they can't use the service. SLAs are mostly aspirational.

The linked article directly talks about this, at this level of downtime customers are promised a 50% discount. That's what the SLA means, effectively
Post reply on HN