Jira Is a Microcosm of What's Broken in Software Development - <AUTHOR> https://linearb.io/blog/jira-is-a-microcosm-of-whats-broken-in-software-development/ <comment><USER2> "Though I think of Jira more like a spreadsheet. Very useful once upon a time. Outdated now. Static. Manual."

This statement is so blatantly wrong that it actually put me off even reading the rest. Spreadsheets are stronger than they've ever been and are never going away, let alone being "outdated." Sure there are products that claim to be "the next spreadsheet" but most of those actually serve a different purpose: no-code app dev.

<comment><USER3> If you're going to make judgements so easily you're going to miss out on a lot of good ideas that people put out there.

<comment><USER4> I would say 90% of tech ideas that area floated out there are awful and I'm being pretty generous with that number.

<comment><USER5> I also tripped on this sentence. But the article is not bad if you charitably read "spreadsheet" as "spreadsheets for bug/project tracking."

</comment></comment></comment></comment><comment><USER6> OP sounds like someone who's unhappy working on big software projects. That's understandable. But once you're on a big project, you can't keep it all in your head. You can't make your own clever adjustments when problems arise without documenting everything and then taking it through channels.

For what it's worth, sales people have the exact same complaint. They can get testy, too, about executives using software-oversight tools to take away the soul of what they really do. Allow me to change 15% of the words in this piece, and it could become a rebuke of Salesforce and its siblings, as applied to large sales organizations. So the brief allusion to sales seemed way off base.

Process can be exasperating, until you've worked in a big place where there's no coherent process.

<comment><USER7> No jira sucks. Azure DevOps spoiled me. Going back to jira is painful.

Is not the process, it's the broken tool. Broken file uploads, general wonkiness and all the minor irritations that just don't get fixed.

Managers choose jira. Developers will create a process but will choose tools that work.

</comment></comment><comment><USER8> > This blog is not about how Jira is too complex and over-engineered with > features I don't need.

This blogpost is a microcosm of engineer arrogance (it's also an ad for their product, so all of this is basically a strawman to drive sign-ups. Great content marketing, to bash on a tool people love to hate).

The world is not all about engineers. Jira is a tool for whole companies, which have lots of other departments than Engineering, which are also important, also trying to reach their goals.

I'm so sorry that you got pulled out of your "deep flow" state because an executive is trying to figure out if a project is at risk. You know, she might have a really good reason to worry about that, maybe including information you don't have, like a potential customer who is at risk if the feature doesn't ship.

So suck it up and help out your colleagues.

And if you don't want to be interrupted, then maybe keep your tickets up-to- date, or proactively communicate risks, or sign out of Slack for a few hours, or get your manager to do their job better and be a buffer to protect you from interruptions. None of this is Jira's fault.

Can Jira be a PITA to use - sure, but that's probably because of how your company set it up. You can make Jira streamlined if you try, but it takes active administration, and the people who work in Jira need to be empowered to work _on_ Jira. If you can't get your Jira project to work the way you need, then that sucks, but that's probably Jira being a microcosm of your company's org/power structure, which is a different thing.

Or sign-up for their product, that's really the goal of this post.

Edit: I did not intend to claim that all, or even most, engineers are arrogant people. They certainly are not, at least in my experience. If you are an engineer (I am one, too) please don't read this as me attacking you personally! I am aiming at _this kind of blog post_ , which displays a me- first attitude that I think is unhealthy.

<comment><USER9> > engineer arrogance

And this is the twilight-zone reality that software developers are forever stuck in:

Manager: "I need you to integrate the TPS reports with JIRA for a client"

Developer: "Ok, I can look into that"

Manager: "How long is that going to take? Put some story points on the JIRA task."

Developer: "Well, I've never done that before, so I'll have to do some research and I can't really say for sure-"

Manager: "I need you to say for sure. Knock it off with your engineer arrogance and suck it up and help your colleagues. I'm so sorry that I pulled you out of your 'deep flow' state but we're trying to reach our goals here"

Developer: (heavy sigh) "Well, a week maybe? If I can focus on just this and not all the other things I'm currently tasked with-"

Manager: "No, subtask it out to individual tasks of no more than four hours each. And you'll need to spend an hour every day in a status meeting so you can spend five minutes updating the status of your subtasks and listening to everybody else's unrelated statuses".

<comment><USER10> I've never seen a manager operate like that and if yours does then you should look into moving.

<comment><USER9> Maybe I've had a 30-year string of bad luck.

<comment><USER11> Considering the litte morality play you typed out includes the exact "developer arrogance" and "flow state" quotes from the OP, I'm guessing this is an exaggeration in anger and it's impossible to argue with until you provide a non-exaggerated example of your 30-year work environment.

</comment></comment></comment></comment></comment><comment><USER12> I recognize that this is a marketing blog, but it blames Jira for what are really culture problems and/or bad management practices.

This is an emblematic quote:

        Take subtasks, for example. The invention of Jira subtasks is an affront to dev teams. Clearly someone who has never spoken to an engineer on a dev team created it. It's the least dev-friendly way possible to get insight into what's happening with a Jira story.

Behind the bombast, the author assumes that the purpose of subtasks is to provide micro-level insight on progress to PMs. I agree that this would be a misuse of subtasks. Speaking as an engineer, I _love_ subtasks because they help me keep track of my various efforts towards whatever feature the ticket is tracking. Also, I'm the one who defines them!

Jira isn't anyone's favorite software, but it is so configurable that it ends up being an embodiment of your dev process. If you hate it, chances are it's because you hate how you're managed.

<comment><USER13> Yes.

I've used Jira for years and never understood the hate.

The only times I have had real problems have been with particular idiosyncratic configurations or conventions that someone at my end has put in.

<comment><USER14> Have you tried the alternatives like YouTrack?

The Jira UX is amongst the worst in the business.

And yet... there it is, on every workplace with an useless operations team.

<comment><USER13> I'm not saying Jira is great. I'm just surprised that people, particularly ICs, _hate_ it.

</comment></comment></comment></comment><comment><USER15> I spend hours per day in Jira. Half as a PM, and the other half as an IC.

I've never used Jira Classic, so can't comment there.

But Jira Next Gen projects have been great to work with. So much functionality and bloat is stripped out of Next Gen, sometimes too much was removed I think.

I hear people hating on Jira very often, but at least the way our company uses it, it's great.

The only thing I'd really want to change is (1) performance, page load times are frustrating, and (2) ability to easily move a ticket from 1 project to another project without clicking through a 6 step process.

Edit: Regarding Jira's slowness, I'd highly recommend trying the Mac app which is dramatically faster than the web ui.

<comment><USER16> > performance

By Atlassian's ToS, you are not allowed to « comment on the performance of the products ». I know no-one thinks this would be enforced here, but I just want to highlight that it doesn't help a company to improve if they know they can just lawyer-up a problem away and avoid benchmarks and being compared on that topic.

<comment><USER17> This is from Atlassian's ToS

 _(d) incorporate any Cloud Products into a product or service you provide to a third party;_

does this mean that I can't integrate JIRA into a ticket tracking workflow that I build for my product with IFTTT that creates a new ticket when someone sends an email to a support alias?

 _(e) interfere with or otherwise circumvent mechanisms in the Cloud Products intended to limit your use;

(f) reverse engineer, disassemble, decompile, translate or otherwise seek to obtain or derive the source code, underlying ideas, algorithms, file formats or non-public APIs to any Cloud Products, except to the extent expressly permitted by applicable law (and then only upon advance notice to us);

(g) remove or obscure any proprietary or other notices contained in any Cloud Product;_

Fair enough.

 _(h) use the Cloud Products for competitive analysis or to build competitive products;_

Sure, I mean this is hard to enforce but if the team at Trello was using JIRA while making Trello, Atlassian could just say "hey - stop, no like".

 _(i) publicly disseminate information regarding the performance of the Cloud Products;_

Seriously? I really didn't believe when I saw parent say _you are not allowed to comment on performance of the product_ but I stand corrected. I will not comment on performance of any Atlassian product ever, ever ever. You got me Atlassian, this is what I get for not reading ToS before clicking Accept.

 _(j) encourage or assist any third party to do any of the foregoing._

Ok.

[0] [https://www.atlassian.com/legal/cloud-terms-of- service](https://www.atlassian.com/legal/cloud-terms-of-service)

<comment><USER18> Wow, that's as dumb as clauses get.

I'll try to get the legal team on it. It's a landmine as even a casual discussion of performance voids the license. Any discussion of outage may or may not involve this point.

It is a devops prevention clause.

<comment><USER19> > even a casual discussion of performance voids the license

Of course, that assumes such terms are enforceable. But, even if not, just having them in there is just so odious as to make one seek out other solutions.

<comment><USER20> Oh of course performance matters. But privacy? Atlassian's privacy policy is even worse.

</comment></comment></comment></comment></comment></comment><comment><USER21> Does anyone else find it pretty obnoxious that this site changes the window title back and forth between "Jira is a microcosm of what's broken in software development" and "(1) New Message!"?

Is this a bug? Who thought this was a good idea?

<comment><USER22> That website is "a microcosm of what's broken" with websites.

Here is that content without that: [https://beta.trimread.com/articles/32605](https://beta.trimread.com/articles/32605)

<comment><USER23> Lol yes! The fixed floating header, the pop-up modal after a few seconds, the long load time for text/image content...

</comment></comment></comment><comment><USER24> Jira is a workflow tool, which also means that most of the issues mentioned here, can be sorted out between the PM and devs on who the workflow should be, and what the rituals for updates should/could be. Jira is flexible enough to accomodate it (mostly). From a developer perspective, some of the points maybe valid, but not from PM perspective.

It would also help if we could get an idea of what the alternatives are, that are better

Edit: Also looks like marketing for the product, than a valid article on Jira pitfalls.

<comment><USER25> I'm using Jira, not a huge fan (mostly because it's slow, the cloud version at least) and there's some clunkyness BUT every time I looked for alternatives it was either too opiniated (like SCRUM or nothing) or had really poor integration with dev tools. The big advantage of Jira is that you can customise it quite a bit and it has a good set of integrations and APIs.

I'm still thinking of moving away at some point but haven't found any alternative...

<comment><USER3> Try clubhouse

</comment></comment></comment><comment><USER26> After working on more than 20 green field projects over the 25+ years I've been a software engineer I can tell you that yes... all SDLC management tools suck at times, but also can be a great part of something very productive. It's how much they are tailored to the needs of the team and how practical their consumption is. I've been a part of projects where JIRA is a nightmare and part of projects where it is a blessing. Same goes for Trello, Asana, Confluence, "just github", etc.

I've also used JIRA where it is ONLY managed by the engineers and also when it is owned and managed by large teams of non-engineering stakeholders.

My 2-cents: When a project isn't going well it's the team that is deficient, not the software, in 99% of cases. Most of these tools can be customized (and combined with other tools if needed) to create something that works... and this varies on a project by project basis. It's not about the tool... it's about how pragmatic and adaptive a team can be as they apply them. Panaceas do not exist in this problem space.

</comment><comment><USER27> Hi Sean here. I work on Jira at Atlassian and I also met with Justin and the Jira Admin for his company prior to this article. I've also heard from him since. He was not consulted re the use of his comments. Generally, I'd encourage vendors to seek permission when citing a customer in marketing in this way. It's a simple respect that can be paid with low effort.

I thought it might be helpful to share a few thoughts on the article. To do that I've added annotations on the article itself using Hypothes.is an open web annotation service. This lets us have a conversation right over the article. I've added a dozen or so comments, gifs and links to help add color from the Atlassian POV.

You can view my comments and add your own via this link or find me at @seanjregan on Twitter. [https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...](https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fjira- is-a-microcosm-of-whats-broken-in-software-de&group=__world__)

Usually we don't engage in the annual articles by competitors that pin SW industry failures on Jira but in this case it seems a lot of what we've been shipping in Jira Cloud is perhaps still unknown. (And, this annotation tool seemed well suited to this sort of dialog.)

Much respect to the LinearB team. Anyone working to make SW Development better is good in our book. Great products will stand out on their merits among the dev community.

While riding the Jira coat-tails via blog titles is a common approach to generating traffic, I want to also note that Atlassian is very open and we're happy to partner with any vendor that can make dev life smoother.

We partner with GitHub and GitLab as an example. If they can do a better job or a customer prefers their tools then it is on us to 1.) Support them and 2.) continue to up our game.

-@seanjregan Add your feedback, comments or Jira tips to the article here. [https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...](https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fjira-is-a-microcosm-of-whats-broken-in-software-de&group=__world__)

<comment><USER28> Hey Sean, Dan here and I wrote this blog post.

Thanks for the effort on the detailed response!

We have a core value at LinearB to empower the dev community and I can see you share a similar passion. The tone of my blog post came off more critical of Jira than intended and it's great to see the improvements your team is making.

Although LinearB is not a Jira competitor, the issue remains that once story planning ends and coding begins, development teams are left with a major gap to stay up to date in real time to support the hundreds of micro decisions dev teams have to make every day. We are eager to address this problem!

It takes hyper correlation between Git and project management tools combined with a developer first mindset (not project management).

Since you are open to partnership, I will reach out to you so we can meet and pursue!

Thanks again Sean.

(I also responded with the annotation tool you used here: [https://hyp.is/A_Sb1N2gEeq1_E8AuivgVQ/dzone.com/articles/jir...](https://hyp.is/A_Sb1N2gEeq1_E8AuivgVQ/dzone.com/articles/jira- is-a-microcosm-of-whats-broken-in-software-de))

</comment></comment><comment><USER29> I hate plenty of things about JIRA, but I'm flagging this post because it's incredibly biased (written by a direct competitor to JIRA), and their site is also extremely hostile to users with their messaging notifications.

<comment><USER30> Yeah it almost reads like a comparison piece. Pretty much all of the points relate back to the fact developers are adding manual updates and how the competitor solves it by integrating Git PRs and commits. However that's easily possible in JIRA now via the integrations (e.g. GitHub) and automations to close tickets depending on the status.

Still, even then with the automations in any of this software to show VCS updates you're going to get managers asking for updates depending on your environment.

</comment></comment><comment><USER31> At least Jira doesn't make popping noises and then show a banner ad that covers the entire page after 10 seconds.

</comment><comment><USER32> Usually Jira sucks because it's not setup correctly to _support_ teams' workflows, instead it's used to impose workflows on teams.

Jira can be as heavy or lightweight as you make it, but most of the suffering I see is because the way teams work isn't being supported by the Jira owners/admins.

<comment><USER33> Sounds like a microcosm of what's broken in software development.

<comment><USER34> Agreed. Jira exemplifies the "you're holding it wrong" software.

</comment></comment></comment><comment><USER35> I used to think Jira was horrible. Then I moved to a company that uses Pivotal. Now I know what horrible means.

<comment><USER36> my feeling to this day is, to paraphrase Churchill, that Jira is the worst possible project management software, except for everything else.

</comment></comment><comment><USER37> I don't have a problem with Jira directly. It's not great, but I've yet to find a project manager that's amazing so I can't say it's substantially better or worse than the alternatives.

That said, I really don't want to work with a PM who _loves_ Jira. It's so flexible and configurable that it seems to really call out to a certain type of PM who adores adding lots of process for the sake of itself. Can we make a 43 step workflow starting with "preliminarily claimed the task", "read the requirements sheet", "read the associated documentation", "opened an editor", "ran 'git pull'", "created a new branch", etc. etc. etc.? You bet we can! I've worked with PMs who really wanted that level of granular visibility into project status, even though it greatly slowed down the work of actually getting stuff done.

So in my experience, you have PMs who _love_ Jira because it gives them a level of control that I absolutely don't want to be involved with, and PMs who think Jira is "eh - it's alright". Atlassian's problem with the latter is that they're just as likely to say "eh, Pivotal is alright too".

There needs to be a Heisenberg's Uncertainty Principle for software development: measuring a process is guaranteed to slow it down, so there's a spectrum between "fast chaos" and "corporate paralysis" that you have to consciously select for, and you don't get to pretend that "fast and tracked to the tiniest detail" is something that's possible.

(Side note: Confluence died for me the day a new version removed the option of editing page markup directly. Up until then, I had a workflow that converted Python module documentation to Confluence wiki markup and uploaded it. When that went away, I vowed never to use it again until it came back. Has it come back?)

</comment><comment><USER38> At the company I currently work for, Jira has become yet another opportunity to engage in metrics abuse. Probably because Jira makes it easy to create reports and dashboards that are more useful for managers than for delivering software.

The company, which has "committed" itself to "embracing agile", has implemented some new employee performance policies which clearly demonstrate those decision makers don't know wtf agile is. One such policy is tying performance to "individual velocity" or story points per sprint per individual completed. Some managers, especially my current manager, care more about individual velocity than what velocity is supposed to be used for.

Consequently, developers can be raked over the coals if their individual velocity dips below a pre-determined number. When my manager confronted me with my lackluster individual velocity over the last few sprints (shown by a Jira report), I first tried to convince him that team velocity mattered more and that it was supposed to be a metric used for planning work for a sprint, not as a forecast metric. I tried to get him to see that velocity for everyone would improve when we got better at prioritizing and creating stories that allowed us to deliver value each sprint. It would also help too if we could function better as a team. But he wouldn't have any of that. I just had to improve my personal velocity.

So I learned how to use Jira better. I created pointed stories in the backlog I knew I could finish in a sprint and meet my forecasted velocity. The next time my manager ran his Jira report, he remarked on the improvement. The amount of work I actually did didn't change, but my individual velocity did.

While I agree with the premise of the OP about Jira. I would go even further than just Jira and say that today, proficiency and mastery of any tool used in the software development lifecycle seems to be more important than knowing how to do software development right.

</comment><comment><USER39> > _The current software delivery process revolves around pushing decisions > down to dev teams and forcing engineers to push status updates back up. This > system ensures executives are the only ones who have context and can see the > bigger picture while engineers do all of the work._

> _This is backwards. It holds us back from building the best product and > slows us down from delivering faster._

Thats engineering. If you don't like it then try to make a career move into management or product or start your own company (not advised).

I myself had to come to terms with reality and have been making the transition.

You got one life, no use complaining until the day you die. Move into management and make the changes. If you're ambitious enough, you should have learned all you need to learn from engineering after 6 years and can apply your knowledge in a more strategic role, running circles around non-technical PMs.

<comment><USER40> _> Thats engineering. ..._

Engineering really doesn't have to be like that. I've worked for companies where the leaders took care to push context down, not decisions. When done right, results are very tangible, and (most) of the devs much happier. A few devs struggle and feel lost - probably the ones you want least on your team.

<comment><USER39> > push context down, not decisions

whats the difference? either way the context or decision is defined by someone else, and you're still the one swinging the hammer.

I actually think there's a major problem in engineering where many don't take charge of their lives and want to guide the decisions. Its a weird Stockholm syndrome love-affair with being the engineer. Idealism is also a problem ( _" it doesn't have to be like that."_).

> (most) of the devs much happier

yeah, but not the ambitious ones I was talking about.

I'm not knocking engineering, I'm saying it's a stepping stone in your career, and not a long term place if you want to influence trajectory within a company.

</comment></comment></comment><comment><USER41> I briefly used Jira, but I couldn't handle the extreme slowness. You click something. Then you wait. And wait. And wait.

<comment><USER16> Cloud or Server? It seems a lot of companies' reputation were broken by clients installing their software on 2GB/1.5GHz servers with HDD, and Cloud will help at least getting a consistent measurable experience of the same product for everyone.

<comment><USER42> In what universe is a few billion instructions per second not enough to respond to a single click?

<comment><USER16> In OSGi universe. Making software which does one thing well is the easy part. Making extensible software with plugins is super-hard.

<comment><USER42> It has been done many times over the last 25 years. I think that's a pretty thin rationalization to having a program freeze when you click a button.

</comment></comment></comment></comment></comment><comment><USER9> What seems to be lost on too many people - including people who really ought to know better - is that 90% of the time, software developers don't know _exactly_ how to accomplish a task, but know how to figure out how. There are two classes of "estimates": "that will take a few minutes because I know exactly what's involved" and "I'm not even entirely sure exactly what's being asked for here, but it sort of 'feels like' this other thing that took about three days that one time before".

</comment><comment><USER43> My struggles with Jira are more that the people who should be in charge of configuring it effectively and running it smoothly (team managers and PMs) often don't. I see a lot of stuff that's incredibly inconsistent and a lot of features that are used incorrectly (most prevalently using labels for EVERYTHING, usually using 4 different labels for the same purpose where say, a component or Epic would make more sense). Exacerbating that is that these ad hoc half workflows aren't communicated effectively, so the only people that understand the systems are their creators

Jira's complex, I get it, but lots of things are. Jira's docs are decent enough--certainly decent enough that following the tutorials will grant you an understanding of the various tools and their intended purpose--but people seemingly just don't read them. Some things just aren't going to be fully discoverable or clear through UX alone.

More galling is that these are usually the same people that then create shadow PM empires through Excel spreadsheets of their own design, which is just ugh. So much blame is heaped on Jira that's probably better blamed on ineffective management.

<comment><USER44> This, exactly. All complaints about JIRA boil down to poor administration, not the tool itself.

</comment></comment><comment><USER45> Well this was disappointing when it turns out this was an advertisement for what looks like clowns building the ultimate micromanaging platform, complete with profile pictures and little status tags and progress bars.

</comment><comment><USER46> Learning Jira and accepting Jira both classic and NG has made me so much money, as a team leader, architect and program manager.

Jira is the user plane for interacting with project items, however like others here said, everything else must be solved with clear communication, frequent ACKs with team members and so on.

Yes, Jira Next Gen is nicer. But classic works fine too!

Also Jira can be a lot of other things. It's really flexible.

<comment><USER47> But at what expense? Does Jira ever frustrate you? Imagine how it frustrates developers that hate working with overly complex time-sink software. I can change my email client. I can change my text editor to my liking. I can change nearly any other tool I use, but when a company uses Jira, I'm trapped using something that mostly gets in my way.

<comment><USER46> I don't have the choice. I am just a cog in the wheels and it helps us do our job.

It's not really in the way, if that's the case it sounds like your processes or workflows are messed up.

I've had days where I don't want to see it, but that's because I'm tired of working. In those times it quick to blame Jira.

<comment><USER47> Oh definitely, the places I've worked have used Jira as a crutch for broken processes and workflows.

</comment></comment></comment></comment><comment><USER48> I really dislike using JIRA, I struggle with it for all the reasons there, and more. But...

"Though I think of Jira more like a spreadsheet. Very useful once upon a time. Outdated now. Static. Manual."

Are spreadsheets really outdated now?

</comment><comment><USER49> I think the author has made the ever common mistake of confusing correlation and causation. Bad engineering orgs often use Jira, but Jira does not cause bad engineering orgs.

Anecdotally, the most frustrating company I ever worked for had obsessive Jira practices, but there was so much wrong with that company I could write a book about it.

</comment><comment><USER50> > Take subtasks, for example. The invention of Jira subtasks is an affront to > dev teams.

Really? Not to me, although I'm not clear when to make a subtask or start using an epic.

<comment><USER18> Generally subtasks are good when it's a single well defined feature or problem and then they are few. To be used sparingly. They're best used like keynotes.

Epics are for broad developments, looser defined. Best used as "bags" of tasks.

Sometimes epics might be disabled altogether and then you have only subtasks, and labels get to be misused as the bags of tasks. I personally consider that a pathological setup. It is much harder to work with and JIRA query tools don't work as well with it.

</comment></comment><comment><USER51> Nice blog post about your new platform I guess.

I do remember working on projects before Jira. My first job out of college managed their software dev lifecycle with Bugzilla. I assure you, it was much worse.

Jira isn't bad, it isn't great, and I honestly don't waste much thought thinking about how bad it is.

</comment><comment><USER52> Jira is very customizable in how it's used. It's sort of like saying that a wall with sticky notes is a bad development tool because of some anecdotal experience. It all depends on what you do with it. Maybe it's more like saying that a spreadsheet is a bad tool.

The only thing I resent jira/confluence etc for is dropping its markdown because it was too hard for the company to maintain :) But they're working on it again. Confluence is probably one of my favorite tools but I haven't used jira in ages as it's possible to get by with github these days.

</comment><comment><USER53> "This is the root of the issue. Jira was made with project managers and product managers in mind. Not dev teams. Project and product managers (collectively referred to as PMs going forward) are the primary buyers and owners of Jira. Not engineers.

Engineers love simplicity and efficiency. Jira is the polar opposite of that."

Why shouldn't project managers and product managers love efficiency, too? If the tools allows the engineers to do their work more efficiently, the development speeed of the team increases - this is what makes project managers and product managers look good.

</comment><comment><USER54> Hm. To me it sounds like they are ranting about micro controlling by too much detail in the jira. Sure, if you have to close 6 tickets for the same line of thought, it's annoying. So don't do that.

And on top of that, the new jira automation + smart commits make stuff much smoother. Assign yourself a ticket, push some stuff with the ticket ID to auto-progress to <in progress>, commit something with "EXA-042 #close" and it auto-closes. Took us some time to get there, but now it's a smooth todo-list for the team.

</comment><comment><USER55> To paraphrase many of the comments here: Most of the problems that devs have with Jira are not problems with base Jira, but with the implementation and usage of Jira.

Jira is perfectly fine, just like ALM is perfectly fine, TFS (Azure Devops?) is perfectly fine, Trello is perfectly fine, etc...

The problems come from the implementation, and the implementation is reflective of the culture. Any work planning tool becomes a work tracking tool and any work tracking tool becomes a punishment tool (without careful and attentive work to stop this effect).

<comment><USER56> It's not the fall that kills you, it's the sudden stop at the bottom.

It is perfectly reasonable to blame the agent of chaos for the chaos that results.

<comment><USER55> ehh, but this is kind of like blaming the results on hitting concrete vs hitting a cornfield. Yes, you might have a slightly less bad time hitting the cornfield, but the height of the drop is the more determining factor.

<comment><USER56> My point is that people love to let Atlassian off the hook. They set up the conditions for failure. You can't blame all of the consequences on the person who touches it last.

It's really the same class of externality that we used to blame Microsoft for. You can try to collect all the cash and all the fame and then blame stability and usability problems on third parties, but not everyone is going to buy it.

If you weren't pandering in the first place, you wouldn't have all that cash or fame. You knew what you were doing. Even if you don't want to say it out loud.

</comment></comment></comment></comment><comment><USER57> I've never understood the hatred for JIRA - it includes a ton of features that many find useful. Yeah it's a PM tool but you need the ability to organize boards and workflows at scale in larger organizations. It's not a tool intended for your startup that can manage with Trello or Github Projects.

This reads like the usual developer's opinion of "the world is not built for me" and "I don't like it if developers aren't thought of first"

<comment><USER58> It's not just a PM tool. There are hundreds of examples at our company where e.g. developers documented various tasks in Jira tickets including steps to take, commands to run, things to watch out for, that benefited me greatly. Sometimes the original developer is no longer at the company, and yet I can find the information in a ticket. Our Jira installation is more like a shared brain than a PM tool.

</comment></comment><comment><USER59> > So why do companies use a tool that works for a few PMs and business leaders > when dozens or hundreds of engineers hate it?

In fact, Jira is so infinitely configurable it reflects the org chart and culture of the company using it. Most Jira complaints I hear are more about that person's company than the tool. That said, the tool definitely doesn't help as much as it should (largely because engineers don't make purchase decisions).

</comment><comment><USER60> Never understood the Jira hate. It's very useful and infinitely better than email.

</comment><comment><USER61> Well, I've been forced to use Jira for a decade or two now. Not a huge fan, but it is ok. Ties directly into gitlab, has a kanban-like board. Every used bugzilla?

But, I've never had any of these other complaints. When will this ticket get fixed? By the end of the sprint. I do tickets in order of priority. Rarely been a problem, so surprised to hear it brought up.

At my current gig, the PM has been there a decade and I only a year, so a great majority of the time I am asking/he is telling me how things should work at a high level. I value the advice.

I did work for one disaster project about ten years ago. Constantly interrupted for fires, tens of hours of meetings per week, and rarely finished sprints. We were overloaded on tickets because sprint planning never took interruptions/meetings/bugfixes into account. We used bugzilla there, but it wasn't the culprit.

Annoyances: just thought of one. The issue page has a ton of stuff I don't care about and de-emphasizes the comments which I'm most focused on. I also don't like how when you click on things it switches to edit mode.

</comment><comment><USER62> Jira lost its usefulness around 2014. It became much too cumbersome to use, and Atlassian's help documentation was/is? out of date. We asked for training, something more than poorly written documentation, and we were quoted an exorbitant price for that training. That was the straw that broke the back and we left Atlassian for good in late 2015 and never looked back.

</comment><comment><USER63> While you do have some valid points, especially when it comes to friction between PM/Devs, the way you seem to be using Jira seems to be the polar opposite of what I have experienced.

Granted, I don't have an overwhelming amount of experience working at different companies, but I feel like the Devs in my company were actually the ones that wanted to use Jira for customization options.

Intriguing!

</comment><comment><USER64> I like jira. Our installation is pretty fast and I need something to track what is outstanding. The query interface is quite powerful, and I can use it to gather evidence that something needs more attention. It's got too many fields but you can turn these off, unfortunately for my org that requires IT so I live with its current configuration.

</comment><comment><USER39> > Jira was made with project managers and product managers in mind

A step further, SCRUM was made for product managers in mind. Engineer-centric Agile methodologies like Extreme Programming are missing from SCRUM guidelines.

Most product management methodologies have a _bring-your-own-engineering- practices_ philosophy, which means they were created in a vacuum.

</comment><comment><USER65> JIRA is just a tool. A pretty reasonable one. It integrates with every dev tool under the sun at this point. It's as lightweight, or invasive, as you want it to be.

Sometimes there's people or workflow problems that get blasted as jira (or rally/ac) problems because that's the interface you see those people or workflow problems through.

<comment><USER18> Nah, generally the point 1 stands. JIRA has potent top down customization tools that are easy to misuse, e.g. adding required fields, task types priorities or defining task flow.

Just that information overload can make working with it a real pain.

These can easily break its own features e.g. scrum or kanban boards or backlogs, which are configured separately.

And the dev or project lead typically does not have access to directly customize it, because JIRA ACLs are way too broad or company has a top down policy on it.

On top of that, it has rather weak support for default values...

Email notifications are also not exactly customizable by the user. It's worse at that front than bugzilla even.

One thing that was sort of customizable are the frontend report views. Shows for whom the app is made - beancounters.

</comment></comment><comment><USER66> Every single project I've been on in the past 15 years (public/private sector, many verticals, different companies), when push comes to shove, people resort to tracking everything on simple spreadsheets or punch lists. And it works just fine (although this results in more communication which is anyway true when things go wrong or overdue, regardless of tools).

So I'm really wondering how much utility a lot of these tools bring (I LOVED Jira in 2006 when it was a glorified table with powerful filters, but I was using it roughly like a smart spreadsheet). I feel a lot of what they add is just busy work that you have the luxury to play with in normal times, but when you don't have the luxury to do busy work, it just slows you down without much benefit.

What have other people's experiences been? An emergency can be a great filter to show you what matters and what doesn't.

</comment><comment><USER67> There is perfectly common sense solution to every issue OP has raised. I have used JIRA for 7 years in many different teams and I think it works and does not get in my way as a developer. In my experience the people who seem to have trouble with JIRA are the same people who have trouble with basic software engineering processes and being organized.

"Bosses (managers) get stuff done through meetings – changing tasks every 60 minutes." \-- I don't know what bosses you are or have worked with but incompetent leadership and poor software engineering acumen can't be solved with buying software subscriptions.

Why are you trying to make for the tool being bad when the blame lies with people? I am tired with hearing this bogus notion of friction between Bosses, PM, Engineers and somehow you can pay your way out of lack of alignment in an organization.

</comment><comment><USER68> Shots fired! It's true though. Using Jira is a struggle.

<comment><USER69> I started tolerating it after discovering it has keyboard shortcuts. Try pressing <shift>+? to see what's available in given context.

\+ Make sure you have it bookmarked as search engine. Also makes it so much nicer when you can jump to specific ticket by using 'j FOO-123' from address bar. Or 'j whatever keywords' to do regular search.

<comment><USER70> I like the dot shortcut - press "." and start typing a command.

</comment></comment></comment><comment><USER71> Having been away from development tools for fintechs for a while I went back to my trusted Jira tool to find it incomprehensible. I also tried & quickly hated Teams & even current Slack. My new go-to tool that anyone in our org or from partners can use immediately is AirSend.io.

</comment><comment><USER72> The attitude embodied in this is unfortunately common. Delivering a successful product is a lot more than just writing code and shipping features. Planning so that you can launch your marketing efforts, ensuring you have a team ready to support whatever you just shipped, or making sure you don't sign new deals that result in 6 months of work needing to get delivered in the next 2 months are all just as important to the business as the day to day work the developers do. Sometimes being a team player means you are a less effective so that other people are more effective. Jira isn't a perfect tool, but the case would be better made by someone who isn't myopically focused on optimizing a subset of the whole product delivery process.

</comment><comment><USER73> Yes. I remember the first time I encountered Jira, I assumed we would just login and start created cards and tasks etc.

Except the first meeting we were introduced to a "consultant" who needed to "design" our process flow before we could do anything.

I went back to Trac needless to say.

<comment><USER56> I think the problem is that Atlassian has designed their tools for information hiding.

I may not agree with Larry Wall on much, but he is credited with one of my favorite aphorisms:

Easy things should be easy, and hard things should be possible.

You can't pre-filter complexity for developers. _That 's our job_. We have to know that there features available even if they have been turned off. Otherwise we're going to blame the tool for skimping on functionality. And we are perfectly right too, because how the fuck are we supposed to know that Bamboo has a feature if the button only shows up for full administrators?

Of course we're going to bag on it. And they deserve every bit of it.

</comment></comment><comment><USER74> I'm definitely feeling this today. I'm effectively locked out of jira today because the new versions of Chrome and FF block cookies that are "SameSite=None" without "Secure", and all of Jira's cookies appear to have this problem.

</comment><comment><USER75> I think the post hit the nail on the head with the question paraphrasing "Why do companies buy project management software that only project managers love But engineers hate?" The answer is project managers manage projects so need project management software.

</comment><comment><USER76> My company uses Jira as our primary tool for development and we really like it's simplicity and effectiveness. With integration with Bitbucket, Trello and Pipeline our developers find it easy to work with. Jira is also easy for non- technical team.

</comment><comment><USER77> The JS-heavy web interface of Jira can be infuriatingly slow, so perhaps the frustrations start from there.

Jira, the project management tool, can actually be great, if you configure it properly. The issue lifecycles, what fields are visible, how the board is showing things etc. can be designed to be as simple or as complex as you want it to be. In addition to that, the integration with Bitbucket and Confluence is also fantastic for referencing issues and features across the code and documentation.

Misuse of a tool does not make it a bad tool.

Disclaimer: have worked on developing a Jira plugin, so my understanding of Jira might be a bit more advanced than that of a novice user (but not by much).

<comment><USER78> > if you configure it properly

This gets into the heart of what I consider to be the biggest issue with Jira, especially compared to nearly every other option, and was disappointed this article wasn't about: Jira is almost a poster child for the "inner-platform effect" [1]. Jira isn't so much an "issue tracker" as it is an "issue tracker development environment", with an ugly PM-focused configuration DSL GUI instead of a more useful to developers script language.

Presumably most of Jira's other technical faults derive from there. It's incredibly slow to use, which is about what you would expect of any program suffering from the inner-platform effect. It presumably has to check layers and layers of "configuration data" to do even the simplest tasks. It's easy to assume the databaase backing Jira isn't well normalized or index-optimized, because you can't build "configurable" normalization. (You might get away with profile-based dynamic indexes, but even then that will only get you so far, especially if your tables are key/value soup where traditional relational DBs fall down at indexing.)

Which gets back to the process failures that the article does talk about because it's easy to suffer from something like the inner-platform effect when your target audience (PMs) don't know what they want until they see it (if they ever figure it out), in part because of the impedance mismatch in the decision<=>development status flow between PMs and devs. So I would say the "inner-platform effect" is both a symptom, a cause, and an exacerbater of those process issues.

(Though I suppose it would be tough for an article directly pitching a Jira add-on to be too critical of Jira's underlying technical problems.)

[1] [https://en.wikipedia.org/wiki/Inner- platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

</comment></comment><comment><USER28> Sorry everyone on the bot. Just yelled at our marketing people to turn it off.

</comment><comment><USER79> I personally found the main criticisms to be insightful reasons why Jira doesn't really add much value to a workflow, but most problems can be dealt with by taking those issues into account and continuing to use Jira. Then again, I'm not entirely convinced tools like Jira are ultimately much better than just managing with email and whiteboarding, which is probably why I feel so meh about it. Everything it does just feels unnecessary 99% of the time.

</comment><comment><USER80> I feel like half of my bosses don't understand what goes in to my teams process for new features. They're probably the ones that bought Jira in the first place.

</comment><comment><USER81> Jira totally removes the fluidity in the software development process, I've stopped using it altogether and now rely on Google Docs and Sheets.

</comment><comment><USER82> The problem with Jira is that a lot of useful features are only available as plugins. But your company won't pay for any of these plugins, or they simply don't want to maintain and install them for security reasons.

So you are stuck with the basic Jira version you company pays for and will never see any of the nice extensions that are available for it.

</comment><comment><USER83> That site is annoying. Popups. Fake "notifications".

As a bug tracker, JIRA seems to be OK. As a development system, not clear.

<comment><USER68> Sorry! We know the bot sucks and we just turned it off. Lame marketing people.

</comment></comment><comment><USER84> Jira does have an extensive and documented API. They have e.g. an official integration / "client" for VSCode. There is a couple of CLI tools.

I hope more alternative frontends will eventually come up to address the UI issues, to streamline particular kinds of usage, etc.

This can't address the API speed, though.

</comment><comment><USER85> You dont appreciate Jira till you no longer have Jira.

<comment><USER18> Depends. I worked using Fogbugz and Trello on different projects and it was a blast in comparison. And another unnamed homebrew which had warts but was still better than overloaded JIRA in some other projects.

Then again I've worked on the project where the source of truth was a set of Excel documents shadowing 5 different ticket systems. Very briefly.

That said if you're lucky, JIRA can be set up to work relatively well. Especially if you keep it simple.

</comment></comment><comment><USER86> I've noticed that more people complain intensely about stuff that's not going away - Jira, Spreadsheets, Twitter...

</comment><comment> awinter-py yeah, there are a couple of up-and-coming tools that try to correlate product spec to tickets while maintaining a separation between the two

hard problems like spec, estimation of work, and assignment of work to people are conflated in a ticketing-only universe

<comment><USER87> Interesting. Can you drop some links to your favorites?

<comment> awinter-py haven't used any so wouldn't endorse, but the general category is 'roadmap' tools or what used to be called 'idea management'

there are some 'release management' or 'launch management' plugins for JIRA that address the other side of the pipeline, but solve similar problems -- also haven't used, but friends who are big-company PMs talk about them

IMO many saas products are inflexible, their strength ('we automate workflows') is also a weakness ('better not deviate from these workflows')

The only project management tool I've heard people rave about is airtable, which is basically an improved spreadsheet UX and not purpose-built for project management.

I suspect the future of project management saas is tools / plugins that provide summary views, but the tickets / specs exist in freeform spreadsheets like airtable. This 'view plugin' ecosystem is alread starting to exist for notion and roam.

</comment></comment></comment><comment><USER88> I wonder if JIRA uses JIRA to track itself

<comment><USER47> It does [https://jira.atlassian.com/projects/JSWCLOUD/issues/JSWCLOUD...](https://jira.atlassian.com/projects/JSWCLOUD/issues/JSWCLOUD-20463?filter=allopenissues)

<comment><USER27> I can confirm we do.

</comment></comment></comment><comment><USER89> Just use Basecamp</comment>


Free Chrome CDs in Best Buy - <AUTHOR> https://plus.google.com/u/0/115980322864066690488/posts/Bb4qaXgYgkz

<comment><USER2> Before people start saying that CDs are dead, keep in mind that the types of people that (a) shop at Best Buy and (b) still aren't using Chrome are those likely to still have an old computer with an optical drive. In fact, they probably feel more comfortable installing software from a CD than downloading it from the internet because it's more "physical" and is endorsed by an "authority" (Best Buy, FWIW).

<comment><USER3> Yes. Totally agree. This was a very smart move made by Google, and it will be interesting to see how it affects the adoption rate of both Chrome and the Chromebook.

</comment></comment><comment><USER4> I was going to write some snarky comment, "I was just thinking it was time to replace my commemorative AOL coasters"...

However, this might be useful for the people who are buying PCs @ bestbuy. Especially if you get the BestBuy associates to hand them out / suggest them when someone buys a new computer. Also, lest we forget, AOL is not the great company it could've been but the free CDs did help make them the giant they once were, they just didn't pivot fast enough.

In conclusion, by having an insightful thought I also got to share my snarky comment.

</comment><comment><USER5> Hey, it worked for AOL. I do think they'd have better luck giving away free USB sticks preloaded with Chrome, but maybe the costs are still prohibitive at this scale.

[On second thought, there are some more issues to consider. In order for them to be useful rather than landfill, they'd have to be writable, but that would be a security nightmare. Imagine someone grabbing one, putting malware on it, and tossing it back in the basket. If they're non-writable, then the question becomes whether they can be manufactured as efficiently as CDs, and with a lesser long-term environmental impact.]

<comment> steve-howard Every thumb drive I've ever found comes in nigh-indestructible plastic casing. I'd say the issue with this idea is less one of malware and more that Best Buy wants all the USB sticks that leave their store to cost $20+.

</comment></comment><comment><USER6> This looks like a superb move by Google, I would pick one up if I was there, regardless.

Marketing wise, it looks great, and will be a wonderful way to put Chrome in front of people who wouldn't be the type to download or even show interest in software on the internet.

These same people are those who associate the Internet with the blue E. The same people who if they get into their heads that Chrome icon = nice experience, may shell out the money happily for a chromebook which gives them what they want.

For what must be a very cheap marketing move, I don't see any negatives to this.

<comment><USER7> Why would you pick one up? Why not simply download chrome. Having a cd is just going to be obsolete by the time you get home. Doesn't make any sense. If you're reading hn, you're probably already quite capable of downloading and installing the software.

<comment><USER8> You can download chrome. Not everyone knows how to do this, or even that it is possible.

<comment><USER7> Yes, there are probably some people that cannot figure out how to download chrome, but those people would also not likely notice any difference between chrome and the browser they already have.

I was referring to the person that commented, reading hacker news probably means this person is both aware and capable of downloading it.

It's just a waste of resources.

</comment></comment></comment></comment><comment><USER9> >The CDs were in really cool plexi-glass cases held together by magnets. The Chrome Expert also gave us the cool idea of using the case as a picture frame after we were done using the CD.

Actually that CD and case does looks quite nice. I would want one myself!

I'm also curious about a Chromebook but I doubt they will arrive in Romania anytime soon. The new Samsung model doesn't seem to be available not even on the German Amazon!

</comment><comment><USER10> Everything old is new again. But, this actually shows you how aggressive that Google wants to market this stuff. Google is Microsoft but is open source friendly. I will ride this wave for as long as it takes me :)

</comment><comment><USER11> My dad loves physical software -- downloading is confusing for him. This is a smart (and inexpensive) move for Google, one that I welcome with open arms, as any effort to get people to stop using anything below IE9 makes my life a whole lot easier

</comment><comment><USER12> They should start mailing it out too. It reminds of this other company that mailed out CDs...

<comment><USER13> This is a great read by the way:

[http://www.quora.com/AOL-History/How-much-did-it-cost-AOL- to...](http://www.quora.com/AOL-History/How-much-did-it-cost-AOL-to- distribute-all-those-CDs-back-in-the-1990s/answer/Steve-Case-1)

</comment></comment><comment><USER14> Following the comments here - Is there really a large untapped market of people that will only use CDs to install Chrome, which Google needs to convert from presumably IE/FF or are they just spending random money? Also, does the installer coax you into starting a Google+ account?

</comment><comment><USER15> oh my god chrome is aol</comment>


Price Discrimination is All Around You - <AUTHOR> http://33bits.org/2011/06/02/price-discrimination-is-all-around-you/ <comment><USER2> Really good article. Bargaining / making deals is all about information.

The US still has laws requiring businesses to put price tags on products to prevent price discrimination.</comment>


I have 40k likes on Facebook..all from India. How do I make money? - <AUTHOR>

As a compliment to my future website, I made a simple facebook app in hopes it would go viral and help brand my company.  I was right. Not only did the app go viral but at the highest, I was getting 12k hits a day and for 6 months have had a steady traffic stream. As a result, I have been getting like after like and now have 40k likes.  Currently I get around 100 likes per day.<p>Sounds great right?  Well here is the problem. 85% of the traffic is from India and Nigeria.  How do I use these 40k fans to make more money?  Currently we have ads all over our app and although very annoying, we make a nice 10$ per 1k hits.  There has to be more ways to make money with all these users and all these likes.  What can I do? <comment><USER2> > _There has to be more ways to make money with all these users and all these > likes. What can I do?_

Likes is not a currency. Get a job.

<comment><AUTHOR> Likes "are" not a currency. I get that, thanks...but there has to be a way to utilize them.

<comment><USER2> But you already monetized the visits, right? You should build on that.

I don't think 20,000 likes are that much to build something on.

<comment><AUTHOR> I get what you're saying I was more trying to imply I have a decent fan base and really no product. I just looked at the fb insights and about 75% of the fans are 18-34 and from India.

</comment></comment></comment></comment><comment><USER3> What's your app name or website address? I'm sure I can help.

<comment><AUTHOR> pixurwall.com/friendsposter - facebook.com/printstreet</comment></comment>


Ask HN: How long to commit to your startup? - <AUTHOR>

It's very common that I hear, "most startups fail because the founders gave up too early". Surely, determination and tenacity goes a long way in creating a startup, but at what point do you decide to cut your losses and move on.
I find that the more time I put into something the harder it is to leave it behind because there is always that lingering optimism that we are at the cusp of exiting the trough of sorrow.
What do you think are good indicators for leaving one's current venture for other opportunities? <comment><USER2> I think you really need some traction from the very beginning, otherwise it is unlikely to be successful.</comment>


How to Calculate the Weekday from a Date - <AUTHOR> https://medium.com/cantors-paradise/how-to-perform-calendar-calculations-5617f35d3070 <comment><USER2> I've got a way easier method. Ask Google or Alexa.

</comment><comment><USER3> Doesn't work for my birthday 06/10/82..</comment>


SnappyData: A Hybrid Transactional Analytical Store Built on Spark - <AUTHOR> http://dl.acm.org/citation.cfm?id=2899408 <comment><USER2> Ah I was really hoping this was just a library that could be used in spark that implements probabilistic data stores. This still looks interesting, but it looks like this would take a lot more work to spin up.

<comment><AUTHOR> It takes about as long as it takes to start up a Spark cluster, and you can interact with it entirely through Spark APIs if that's what you're comfortable with. It can also be used in "Split Cluster Mode" so you can use your existing Spark build instead of what's embedded within SnappyData if you prefer.

<comment><USER2> Right now it is easy for me to spin up a spark cluster on YARN, but hard for me to acquire a number of machines to run arbitrary code.

</comment></comment></comment><comment><AUTHOR> Github repo: [https://github.com/SnappyDataInc/snappydata](https://github.com/SnappyDataInc/snappydata)

<comment><USER3> So, you guys forked gemfire, spark and spark-jobserver. Are you planning on going back into mainline or will you be maintaining the forks to stay current at some interval?

<comment><USER4> Just to be clear, we do support Snappydata as a library (unfortunately, the docs don't make this clear) that can work with your distribution (upto 1.6 today). Our releases will support the latest Spark version in a staggered manner.

Everything we have done is an extension to Spark. None of the existing functionality is lost. In a sense, we have turned Spark to work more like a database. So, don't think we can turn it back into the "mainline" (assuming that is what you meant).

</comment></comment></comment><comment><USER5> How much of this is still relevant with the upcoming 2.0 structured streams?

<comment><USER4> Structured streaming really makes spark much more competitive for streaming use cases by allowing streams to be seen as DataFrames and hence make it super simple to run continuous queries using SQL on streams, but, often you also need to work with historical data in your analytic query, continuously mutate data (which may require transactional semantics), make sure the data itself is HA (not just fault tolerant; important for low latency apps), etc. What we do is fuse in modern in-memory DB with spark (i.e. DB cluster nodes run spark executors) so there is no need to couple spark with some other data management cluster. That said, some of the APIs we introduced for SQL stream processing will be replaced by the new Structured streaming APIs.</comment></comment>


Testimonial Is King - <AUTHOR> https://kuanysh.com/published/testimonial-is-king <comment><AUTHOR> An OP here. If you have any questions, shoot them here.</comment>


CSS3 lasers - <AUTHOR> http://motherfuckinglasers.com/

<comment><USER2> CSS3 offers a lot; essentially it can let you programmatically draw whatever you want fairly easily. While it's cool to see demos and fun things made with it, I'm about as impressed by most "look what I can do with CSS3" things as I am with "look what I can do with <insert graphical design software here>". That's not to say that neither can create amazing things; I'm just noting that since it's apparent CSS3 is quite powerful, it'll take more to impress me. Regardless, it's always fun to see these things :)

</comment><comment><USER3> Source Code for the curious...

lasers.coffee [http://github.com/evilhackerdude/lasers/blob/master/lasers.c...](http://github.com/evilhackerdude/lasers/blob/master/lasers.coffee)

lasers.sass [http://github.com/evilhackerdude/lasers/blob/master/lasers.s...](http://github.com/evilhackerdude/lasers/blob/master/lasers.sass)

<comment><USER4> It would be nice to have them animated with CSS transitions...

<comment><AUTHOR> There were webkit animations in the beginning though the framerate was too low.

</comment></comment></comment><comment><USER5> I was disappointed when I realised there was no background electronic MIDI music.

<comment><AUTHOR> Refresh — I added some deep Hans Zimmer for hearing pleasure while watching the lasers.

<comment><USER6> Hans Zimmer, my colon. You really are evil, evilhackerdude.

<comment><USER7> How about this as a modern alternative: <http://soundcloud.com/shamantis/j-biebz-u-smile-800-slower>

</comment></comment></comment></comment><comment><USER8> Woah: I recognize these exact laser patterns and colors. I feel like there are school photos of my cousins from the late 80s or early 90s which have this pattern as a backdrop. Did you have a reference image?

</comment><comment><USER9> I don't mean the undermine the skill required to achieve this but why would you use CSS to do something like this? I've also seen stuff like pure CSS logos, pure CSS fail whale, etc. and I have no doubt it helps you understand CSS inside out but what is the practicality of it? I love it, but I just want to know why you'd prefer pure CSS over images or some other way to display similar effects.

<comment><USER10> This is effectively a vector image. It can fit any window without losing quality. Something like this could also be done with an actual vector image (and there should eventually be good SVG support in all browsers), but I think CSS might give you more control in some situations.

</comment></comment><comment><USER11> From [http://ipinfo.info/netrenderer/index.php?url=http://motherfu...](http://ipinfo.info/netrenderer/index.php?url=http://motherfuckinglasers.com/&browser=ie6) to [http://ipinfo.info/netrenderer/index.php?url=http://motherfu...](http://ipinfo.info/netrenderer/index.php?url=http://motherfuckinglasers.com/&browser=ie8..). At least the font got better.

</comment><comment><USER12> Oh jeepers! - definitely not work safe. My boss was pretty much directly behind me when "MOTHERFUCKING LASERS" appears on my 24" screen in massive letters.

This is the one time I'm glad the place I'm working is so backward web-wise, as the lasers didn't work - no CSS3 for me! - and thus my screen wasn't turn into even more of a profanity-emblazoned eye-magnet.

So thankfully, she didn't notice. Phew.

<comment><USER13> Lawks, it must suck to work in a factory where scented water is puffed onto doilies by baby deer with adorable eyes (I am guessing). But seriously - "motherfuckinglasers.com" didn't alert you?

<comment><USER12> Well. Yeah, I guess it kinda did. Sorreee muuum. :)

And you guessed right. _Someone_ has to make all those liquid-center scented baby-dolls, right? And it just so happens that doe-eyed deer are particularly capable. Just a bit work-shy, which is where I come in and whip them into shape.

Edit: Hey! Why do I lose karma?! Was it the whipping part...?

Edit: Thanks. :)

</comment></comment></comment><comment><USER14> Impressive effects without using images.

Unfortunately: There are rendering problems in Firefox. It's a fixed size and doesn't scale with the browser window resolution. The same page can be achieved in a widely compatible way with a simple image.

<comment><USER15> It's a tech demo, not a cross browser compatible widget.

</comment></comment><comment><AUTHOR> Scientifically proven thanks to modern laser technology: According to Google Analytics adding "Rick Astley - Never gonna give you up" decreases Avg. Time on Site by 2 seconds.

</comment><comment><USER16> I was expecting more pewpew

</comment><comment><USER17> So, I don't see anything. I'm guessing many others don't as well.

<comment><USER18> So, I see something, but feel I must be missing the pièce de résistance here. There's a background covered with parallelograms and the words "Mother-Fucking Lasers" that flash every once in a while.

Should I be seeing something else? (I'm using Chrome on Ubuntu.)

</comment></comment><comment><USER19> Can you make the audio loop?

<comment><AUTHOR> No, that's just wrong.

Ok, I couldn't resist.

<comment><USER20> Apparently, I Rickrolled the managers standup today by tweeting this. Thank you.

</comment></comment></comment><comment><USER21> Needs more CSS3 sharks

<comment><USER22> <strikeout>sharks</strikeout> cowbell.</comment></comment>


Show HN: Loadmill – Run Load Tests with Real Crowdsourced Traffic - <AUTHOR> https://www.loadmill.com <comment><USER2> Great idea, the sample of random users will probably be a lot more representative of actual traffic than the usual load tests!

Are the users of the affiliate websites aware of what is happening though?

From an ethical point of view I think this is no different than ads, so it's fine. Ads however are self-evident, so if I don't approve of them I can avoid the website in question.

<comment><AUTHOR> Thanks!

Yeah, our affiliates get a visible iframe to embed in their website, and that is their responsibility to communicate this to their visitors (they can also do it in other ways).

This should work really well blogs and websites who want to avoid ads and look for alternative monetization models.

</comment></comment><comment><USER3> I have a few websites that I needed to monetize and this looks perfect. Can't wait to use it.

<comment><AUTHOR> Thanks mipmap, ping me if you need any help with that.

</comment></comment><comment><USER4> This seems like a very good and cost effective solution to test my website, I'll be in touch :)

</comment><comment><USER5> This is an awesome service! Simple, easy and cost effective! Great job!

</comment><comment><USER6> Liked the idea. Thinking out of the box.

</comment><comment><USER7> Where does the traffic come from?

<comment><AUTHOR> Hi Linde, the traffic comes from our affiliate websites' visitors. They perform a set of limited http/s requests to the tested application.

This way we can offer our affiliates an alternative monetization model. Website owners embed our script, and share the revenue generated from the tests they help to power, while keeping their website free from ads.</comment></comment>


Japan offers most paid leave for fathers but few take it, UNICEF report finds - <AUTHOR> https://www.japantimes.co.jp/news/2019/06/13/national/social-issues/japan-offers-paid-leave-fathers-worldwide-take-unicef-reports-finds/ <comment><USER2> > the third most common reason given was an "unfavorable atmosphere" in the > workplace. The top reason was staff shortages and the second most common > reason was that their company did not offer it.

If the company doesn't offer it, then they don't have a choice.

If they're short-staffed, that's (most likely) an atmosphere the company has created to keep labor costs low.

So the #2 reason shouldn't even be on the list, and #1 is essentially the same as #3. In other words, "unfavorable atmosphere" is the #1 reason for choosing not to take available paternity leave. This is no different from American companies that offer "unlimited" vacation time but create a toxic work culture where everyone feels guilty for using it.

<comment><USER3> I would be curious if these companies put similar pressure on women to forego their maternity leave, or if the pressure is only directed against men.

<comment><USER4> Anecdotally, my female Japanese friend outright rejected the idea of going back to work after having a kid and said that lots of her friends feel the same way. There seems to be a strong cultural thing around women becoming stay-at-home mom's instead of rejoining the workforce.

</comment></comment></comment><comment><USER5> I worked at various companies over there and bluntly asked why no one used up their PTO and/or took vacations longer than a day or two. The reply was always: taking any non-trivial amount of time off is perceived to be the sign of a lazy person, I don't want to make waves.

This lines up quite well with their expression, "the nail that stands up gets hammered down." Don't stand out.

There have been cases where people taking a full week off were let go due to this perception of ineffectiveness. Obviously there is societal pressure going on here, but I truly hope it changes.

<comment><USER6> Is there an abundance of competent workers over there? Companies can easily replace people? It just seems like bad economics to fire people for taking a week off, even if they're perceived as lazy in the short term. It is usually a lot more expensive to hire and train replacements. (I thought)

<comment><USER7> The labor market in Japan works very differently than in the U.S. Once your fired or forced to quit from your salaryman job it's much harder to find a replacement than in the U.S.

<comment><USER8> That must mean there are few options to earn income (with an acceptable level of risk) in order for employers to have that much negotiating power over the employee.

The acceptable level of risk is, of course, subjective and what is unacceptable in certain societies might be fine in other societies.

<comment><USER5> Japan has traditionally moved people forward lockstep. For example, you and 19 other people join Very Large Company on April 1st (their fiscal new year). You will all be inserted into a department and work there for 3 years. You will all be promoted at the same time. You will all revolve around to new departments in 3 years.

If you are an outlier and get ousted from Very Large Company you are now unable to join a new company lockstep with college graduates. You are a mid- career outcast, and now need to start considering other options.

To be fair, I feel like the IT industry is a little more lenient in this regard. I met a lot of incoming mid-career folk at the game company I worked at, for example.

I think as a society this is changing, especially now that the younger generation is more inclined to "do their own thing" \- work part time jobs, not work, rotate through jobs, etc., but it may take some time to deeply change until the previous generation rotates out of the work force (which won't happen soon, something like 60% of the workforce is over 50 right now).

</comment></comment></comment></comment></comment><comment><USER9> >Of those who did not take advantage of it, the third most common reason given was an "unfavorable atmosphere" in the workplace.

This brings to mind stories of workplaces in the US that officially offer unlimited vacation time but no one ever takes it because actually using it is viewed so negatively.

<comment><USER10> There is no such thing as unlimited vacation time. If you want to know how much vacation time you have, ask your HR manager at your "unlimited vacation" org how much vacation they're required to pay out by law if you separate from the org.

<comment><USER11> I interviewed with such a place and started questioning them about what this really means. How much do people take on average? What would be unacceptable? The response was pretty much something like "You can take off when the workload and your projects allow it" and they didn't give any hard numbers. It made me wonder if people there actually take less vacation than the usual few weeks.

<comment><USER12> In my experience it leads to less vacation for most workers. But some people take advantage of it without raising suspicion.

The average worker has no baseline for what amount is appropriate. They think they are always too busy. Their boss thinks they are too busy.

But some people get more by being untransparent. If I'm going on a fishing trip, I don't tell anyone. If something comes up, "I'm out of the office, I can meet when I get back or do a call." Nobody knows if I'm traveling for work or vacation.

<comment><USER13> > But some people get more by being untransparent.

Untransparent...mmm...I think I like I that word :)

</comment></comment></comment></comment></comment><comment><USER14> It really depends on the culture of the company. In my company (95% Japanese/non-gaishiki-kei) it's the norm for people to take a couple months off when there's a new addition to the family. I took 6 weeks when my son was born and nobody batted an eye. My friend, who also had a child around the same time me, couldn't take parental leave, but said he'd be working remotely a lot instead.

I'm optimistic it will change, but probably not for another long while.

</comment><comment><USER15> I work with a guy who took it for three months without having worked a day at the place besides orientation. The company knew about his situation prior to hiring him and were totally fine with it - they even arranged gifts etc. The place I work is Japanese but takes a lot of pride in shunning the work culture commonly associated with Japan.

<comment><USER16> I love reading these kind of stories about Japanese companies. I hope there are more and more of these as the current work culture over there is pretty depressing to me.

</comment></comment><comment><USER17> To me, the most surprising factoid in this article is that Estonia offers 86 weeks of maternity leave! That's so much! And with such a low cost of living... goodbye, Bay Area.

</comment><comment><USER18> Iceland basically made paternity leave 'mandatory':

> _The country passed a law that granted three months of non-transferable > parental leave to both mothers and fathers; an additional three months of > leave was granted to the couple to share as they chose._

> _By most measures, the law was a rousing success. About 90 percent of > Icelandic fathers take leave. In 2007 (the most recent year for which I've > found data), fathers in Iceland took 101 days of parental leave—almost > exactly 1 /3 of the family's total benefit days._

* [https://slate.com/human-interest/2013/04/paternity-leave-in-...](https://slate.com/human-interest/2013/04/paternity-leave-in-iceland-helps-mom-succeed-at-work-and-dad-succeed-at-home.html)

Of course fathers can choose to take zero, but then that time is basically lost. Further changes (ibid):

> _The law was such a success that Iceland recently went a few steps further > with a 5-2-5 policy: Mothers and fathers will soon each be entitled to five > months of non-transferable leave, with an additional two months of shared > leave._

Anyone from IS that can comment on this policy?

</comment><comment><USER19> I worked for a US law firm in Tokyo for a number of years; my paternity leave was 3 days and I was expected to field emails as and when needed.

It is a race to the bottom, my friends - believe it.

</comment><comment><USER20> It's probably because of the work culture. Many people won't leave work at the end of the day until the boss leaves.

<comment><USER21> They just need to do like me! Start seeing their wife as the boss!

<comment><USER22> when i request vacation the email reads "boss says i won't be at work between the following dates."</comment></comment></comment>


Stop Looking for a Cofounder - <AUTHOR> https://medium.com/@johnwheeler/stop-looking-for-a-cofounder-ad6e8f972776#.5aqqvjeci <comment><USER3> It is a false assumption that pg's advice universally applies to all business. His advice is specific to startups, as defined by the SV crowd, which means extreme growth, intending to take on investors. If that path is not specifically in your plans, a lot of the advice coming out of VC/YC mouths should be taken with a grain of salt.

</comment><comment><USER4> Many great companies can be started in 2016 as a solo founder. Not every company needs to be the next Google to be massively successful and rewarding.

Look at the Forbes 400 list. There are literally hundreds of solo founders who are the wealthiest people in the world.

Always remember, no cofounder is better than the wrong cofounder.

For those who want to understand execution, I highly recommend reading The 10x Rule by Grant Cardone

<comment><USER5> I am interested in your review.

</comment></comment><comment><USER6> The majority of "no single founder" advice I have heard are from investors, and that obviously includes PG as well. It is important to realize that investors have many incentives to fund companies with more than one founder. Not all of those incentives necessarily align with the incentives of the primary founder.

Being a single founder has some obvious disadvantages, but considering how many times "cofounder disputes" is cited as one of the most common reasons startups die, often by the same set of people with the above advice, I can't help but wonder if the benefit of derisking that particular concern by being a single founder is underappreciated.

<comment><USER7> Interesting point. Is this an issue of governance? To an investor, it's important to not have a single point of failure at the head of a company. If there are 2 founders and one loses interest or gets hit by a bus, the company survives. (Or to be more Machiavellian, if one is unreasonable, they can oust them without losing the company) If there is 1 founder, the power dynamics are different, because they have a much stronger hold on leadership and information. And more key-man risk.

</comment></comment><comment><USER8> I'm a solo founder. When I started my current company, I first developed a prototype then tried looking for a co-founder shortly after. There weren't many options within my personal network (few risk takers or people with savings to burn). I expanded my search to those I didn't know, which meant going through essentially an interview process with potential candidates, but I couldn't find a match. I even had people do reversals and pitch me their ideas.

My feeling is that this kind of co-founder matchmaking is just plain hard. First, like they say it's similar to getting married. You really need to trust the person, which is why your personal network is the best source if you can pull it off (see PG talk about college buddies). Second, many people interested in entrepreneurship probably have their own ideas already.

I think non-technical founders have the best chance at recruiting technical founders than the other way around. The technical role is more straightforward (write code for the idea that the non-technical founder came up with), and potential technical recruits may be more wealthy on average.

If you're a technical founder, I'd say recruiting a "biz" person is a lot harder. Fortunately, you can just do everything on your own anyway (not that it'll be easy though!).

<comment><USER9> Can you point to anything about PG and college buddies? I'm not seeing much on the subject.

<comment><USER8> Here he mentions staying in contact with college friends for use as future co- founders: [http://paulgraham.com/notnot.html](http://paulgraham.com/notnot.html)

Here he mentions founders knowing each other since elementary school: [http://www.paulgraham.com/founders.html](http://www.paulgraham.com/founders.html)

I believe I've also seen him on video saying that the best cofounders are old friends. I've always had this impression that he doesn't believe in "founder dating" or quick matches like that.

</comment></comment></comment><comment><USER10> I've had people approach me to be their cofounder on their projects, and I have almost always said no, because A) I have my own projects I'm interested in working on, and B) I didn't think _they_ brought any useful skills to the table.

When you're teaming up with a cofounder, you're not just getting a free employee. You're getting a business partner, and that person needs to be someone who complements your skills. But too often, I see MBA types who are "looking for technical cofounder for lots of equity" to mean "need a code- monkey who I will boss around for free."

Even more distressing is the fact that so many young programmers will go along with it.

If we're going to be cofounders--and let's just assume for a minute that I have the technical part covered--then that means I expect you to be able to prove that you know how to perform the tasks of marketing and sales. I can show you several past projects I've worked on. What can you show me?

And you need to be putting in just as much effort on your job as I'm putting in on mine. And no, you are not waiting for me to finish the product. That's not how marketing works. You need to start _now_.

Nobody has managed to do that yet--and there have been several suitors--thus I haven't taken on a cofounder.

<comment><USER11> That is my experience as a technical cofounder. If your partners don't have the marketing or sales chops, you will live in a constant world of blame where they are waiting on you to complete the product. If only you could figure out how to do that last big feature, we could sell it... This customer says they will buy if it can do this...

I think this is a very common refrain in small startups. If the business side can't sell it, it must be that the product isn't good enough yet.

<comment><USER12> > I think this is a very common refrain in small startups. If the business > side can't sell it, it must be that the product isn't good enough yet.

Correct, but fwiw, and speaking as a techie/marketer/sales I've more often than not seen this happen when the techie founder is not involved in the sales process at all, so methinks the blame is largely shared between the founders - you can't just blame the sales if whoever might be able to say "hey this is _super_ complex, are you sure you need it _now_?" is not around during the discussion.

</comment></comment></comment><comment><USER13> It's good to have someone there to push you, and vice versa. But definitely don't putz around wasting time looking, when you could be spending that time building. Bringing your idea to the light, getting critique from peers and users, is much more valuable starting out. If I waited to work with someone for every idea I had, I'd never get anything done. Worry about all that other business related nonsense when something actually gets traction.

</comment><comment><USER14> I think these are all really good points, but I was sad to see it didn't address one of the largest reasons my side-business is going to stay side- business until I find someone I can envision really starting with -- you need someone to lift you up.

I sit in the school of thought that says you need a co-founder to disagree with you with a passion you won't find idly perusing Reddit, but you raise a few good points. One thing you don't address is the overwhelming feelings of "I can't do this" or "I shouldn't do this". Those are the points where you need someone you trust to be on your team, because it's likely these moments of despair won't sync between the two of you.

<comment><AUTHOR> You're right - it's addressed at the bottom too

"The last part of the quote above, that you need colleagues to cheer you up when things go wrong, hits home for me. When I started developing eBay software, PayPal's recurring payment system had a bug that was skimping my payouts more and more each month. It took me three months to get them to fix it, and although they ended up reimbursing me, it was stressful watching my revenues erode while my user count increased. In addition to crises, it's also hard just staying motivated sometimes. The best way to cope is to maintain low expectations and stay busy working on things you can control."

For the emotional aspects of business, you DO need people. I posted this on HN because of the incredible stimulation I get around the discussion from all you.

<comment><USER14> Sorry about that, I thought I had done a thorough read and obviously hadn't.

</comment></comment></comment><comment><USER15> 3 LLCs, a trademark, a patent application, and 10 years later and I've learned so much more of solo founder success has to do with pure dumb luck. I've since given up. For every success story like in the article, there are 10 failures.

<comment><USER10> For every success story, period, there are 10 failures. Even if you find a cofounder, you're still likely to fail.

I think the point of the article is just an admonition to not _ensure_ failure by settling on a _bad_ cofounder under the idea that any is better than none.

</comment></comment><comment><USER16> > However, I created ebay feedback software by myself that's kept me self- > employed for the last four years

Commendable. But this seems to be what investors often call a "lifestyle business". Not the kind of thing that needs a team to grow.

</comment><comment><USER17> The reason people look for cofounders (and why firms requires multiple cofounders for investment) is not a skill/productivity issue.

It's a _risk adversity_ issue, as if something happens to a single cofounder, the startup is 100% dead.

<comment><USER18> > _It 's a risk adversity issue, as if something happens to a single > cofounder, the startup is 100% dead._

I think a keyperson insurance policy would be much simpler to arrange, though only _maybe_ less costly.

<comment><USER19> Try getting key-person insurance for a solo startup. A cofounder is cheap by comparison.

</comment></comment></comment><comment><USER20> Happened to sit next to a billionaire at dinner once. He asked me what I did. I said I ran a small business. He asked did I have a partner. I said I did. He said: "Get rid of them".

Suffice to say I am not a billionaire.

<comment><USER21> Ha my dad says the same thing, though he's not a billionaire. Says they're always more trouble than they're worth

</comment></comment><comment><USER19> The rule is pretty simple if you are bootstrapping. A cofounder makes your life easier now at the expense of making it harder in the future - <USER2> ultimate technical debt.

</comment><comment><USER22> This is my advice: If a cofounder sounds right for you, you're probably doing the right thing by looking. I've tried several startups without a co-founder and I can tell you that having a partner helps immensely. Having someone in the trenches living for the same cause brings a spirit that's hard to conjure by one's self.

Sometimes it's easy, and sometimes it is difficult. The co-founder I'm working on Baqqer with happened because I posted in a FB group looking for a designer/front-end person that could share in some of the work. I had recently sold everything and moved in to my van to conserve my burn rate while I was building out of TechShop. My co-founder told me one of the reasons he joined up was because he found it inspirational that someone would go to such lengths to live for what they wanted to build. We get along as friends first and I think that's the most important trait required for early stage co-founders.

If you're looking for a co-founder I'd suggest just being open and honest with what you're building, tell your story, grow your community, build something people want. You also might have some luck over with the Baqqer community with the rest of us. [https://baqqer.com/](https://baqqer.com/)

[edit] I'd also like to point out that I was building while I was looking, so I had something to show that demonstrated my desire to keep moving forward and demonstrated progress on the idea. This is a good place to be. I'd say don't show up empty handed when trying to find a co-founder.

<comment><AUTHOR> hey, we have the same logo

[https://feedbackboost.com/](https://feedbackboost.com/)

font-awesome FTW!

<comment><USER22> Hahah yeah, it started out as a placeholder. We're re-thinking the logo and considering something that demonstrates the utility of a community that works together to produce something. There's a trello card and everything! :P

</comment></comment></comment><comment><USER23> You make some good points, but I think the piece could be a lot better if it weren't framed as a rebuttal to pg's article.

I know that it is far easier to come up with something to say at all when you have something to respond to and I know how tempting it is to latch onto a prominent figure and disagree with their famous ideas. But it is psychologically an uphill battle. It undermines your actual message by reinforcing the assumption that multiple founders is the status quo and you need to battle against it to go solo. That idea just feels exhausting to contemplate.

If you plan to write more on this subject, I would be interested in hearing a great deal more about specific success stories and the insider perspective in terms of process and how your day goes.

Edit: Inspired by this piece, I wrote my own blog post. [http://micheleincalifornia.blogspot.com/2016/06/working- is-l...](http://micheleincalifornia.blogspot.com/2016/06/working-is- lonely.html) ([https://news.ycombinator.com/item?id=11912395](https://news.ycombinator.com/item?id=11912395))

It in no way references this piece. It took me a really long time to figure out how to write something inspired by something I had read without making it a rebuttal or direct response to the thing I had read. So, as noted above, I am totally sympathetic to why that happens. And, to reiterate what I said above: I would sincerely be interested in seeing more info about what working alone is all about.

Thanks.

</comment><comment><USER24> Cofounder helps because you have blind spots, there's a lot of work to do, and they can split startup costs. But, be very sure to understand what drives them, and what their threshold is for bailing.

</comment><comment><USER25> Anyone have more information on that PayPal bug?</comment>


LIVE – over 200k protesting in Romania over abusive politicians - <AUTHOR> https://www.privesc.eu/Arhiva/73194/Protest--NU-Legii-Amnistiei-si-Gratierii--D--Day- <comment><USER2> The protest is about the principal ex-communist party (called P.S.D), that won the parliamentary elections two months ago, and then passed a law decriminalizing corruption and freeing their corrupt party members from prison or ongoing cases. People have had enough of corruption and stealing.</comment>


Apple's AirPods are smart wireless earbuds with a new W1 chip - <AUTHOR> https://www.engadget.com/2016/09/07/apple-airpods/ <comment><USER2> Wired headphones:

\- "Just work"

\- Never run out of batteries (in less time than a cross-country flight!)

\- Have impeccable audio quality (well, not AirPods, but...)

\- Can be hung on your neck for a quick conversation

\- Are protected from falls by the cord

<comment><USER3> Add to that: never get separated so that you always have two earbuds! I see these quickly becoming an annoyance when you can find one earbud but for the life of you can't locate the other.

<comment> k-mcgrady Considering the shortish battery life and the fact the case is a battery pack I suspect most people will always have the case with them and always put them into the case when not using them. That might limit this problem.

<comment><USER4> I love that I can keep earbuds in a pocket, but there's no way I can keep a case like that in my pocket. I guess I'll be using the included dongle.

<comment> k-mcgrady I think the case looks pretty small. Hard to tell from the videos but I'm hoping it's small enough that it's no big deal to put it in my pocket.

<comment><USER4> There is no way I am going to be sitting on that hard plastic case.

</comment></comment></comment></comment></comment></comment><comment><USER5> Lightning and proprietary wireless standards are "the future"? Garbage. Apple is segregating the audio market.

If you truly believe in your tech, make it an open standard. The future will not be owned by a single corporation.

</comment><comment> k-mcgrady If these work as well as they say they will I'm pretty excited about them. Making the case a battery pack was a pretty cool solution to the limitations on battery size such a small device has. I was worried about damage if they fall out but after thinking about it the only time my EarPods fall out is when my arm catches the wire so I guess they should be fine.

</comment><comment><USER6> Price just revealed, $159. Seems about $100 high to me.

</comment><comment><USER7> New business idea, sell a lightning male to mini jack male cable allowing a lot of high end headphones to simply convert by replacing their cables.

<comment><USER4> ... That connector is already included in the box of every iPhone 7.

<comment><USER7> They have a lightening to female mini jack. Not a 3-6ft lightening to male mini jack.

<comment><USER8> Or, better yet, a wireless dongle to male mini jack. The guts of these things have to be small/light enough to clip to the side of a high-end set.

</comment></comment></comment></comment><comment><AUTHOR> Poor Bragi.</comment>