Dreadnought hoax - <AUTHOR> http://en.wikipedia.org/wiki/Dreadnought_hoax <comment><USER2> "During the visit to Dreadnought, the visitors had repeatedly shown amazement or appreciation by exclaiming "Bunga! Bunga!".[7] In 1915 during the First World War, HMS Dreadnought rammed and sank a German submarine—the only battleship ever to do so. Among the telegrams of congratulation was one that read "BUNGA BUNGA"."

<comment><USER3> Berlusconi does seem to have rather ruined (or improved!) that phrase for the rest of us, judging by the Bunga Bunga wikipedia page.

</comment></comment><comment><USER4> Dreadnought by Robert K. Massie is a sprawling, fascinating read of the run up to the First World War from a naval/arms race perspective (it has a sequel too, covering the outbreak of war onwards). I highly recommend it.

[http://www.amazon.com/Dreadnought-Robert-K- Massie/dp/0345375...](http://www.amazon.com/Dreadnought-Robert-K- Massie/dp/0345375564)

</comment><comment><USER5> > Stephen wanted to take command of a platoon of German soldiers and lead them > across the French frontier to cause an incident.

I imagine the possible consequences if they went with that plan. That was the decade that eventually led to the first world war. Relations between France and Germany weren't at their best.

<comment><USER6> Alternatively, it could have served as a pressure relief valve.

<comment><USER7> Probably neither; critically, by then France on its own wasn't a match for Germany, no matter how much they lusted for revenge for the 1870 Franco- Prussian war and recapture of the provinces of Alsace and Lorraine.

As one book I'm reading notes, of the great powers, only France and Russia has a desire to upset the status quo (Russia was motivated, as always, by a desire for a secure warm water port, and this time, by Pan-Slavism WRT to the Balkans, recently freed from Ottoman bondage).

<comment><USER8> _> of the great powers, only France and Russia has a desire to upset the status quo_

That wasn't really the case, though; during this period Germany was very busy upsetting the status quo by expanding their navy, which directly challenged the UK's position as the world's pre-eminent naval power.

<comment><USER7> I count these differently. It comes down to intent vs. capability: was Germany intending anything more than becoming a greater power (I'm still reading up on this)? As a serious nation the UK of course had to react to the increased capability, but I view this as qualitatively different than France's crystal clear intent of taking back Alsace and Lorraine, which also was backed up by some serious capability.

Russia intended to help the Balkan nations stay out of the non-Slavic (in terms of rule) Austrian-Hungarian empire, however their capability to directly affect this was limited by geography (again, something I'm in the process of reading up on).

(There's also the forward looking detail: France was a declining nation (e.g. declining birthrate), Germany a growing nation. That put a time limit on their capability to carry out their intent.)

</comment></comment></comment></comment></comment><comment><USER9> If you think that's impossible to do now a days see this: a Modernd day Hoax of a 20 y/o disguissed as a powerful politician, for months. [http://elpais.com/m/elpais/2014/10/23/inenglish/1414066819_4...](http://elpais.com/m/elpais/2014/10/23/inenglish/1414066819_431453.html)

This was discovered this October.

</comment><comment><USER10> Of course, such a stunt today would result in criminal charges of "terrorism" and lengthy prison sentences, all the while politicians would excoriate the hoaxers as enemies of the state.

<comment><USER11> Probably not - or rather, such a stunt by anyone else would've resulted in criminal charges and lengthy prison sentences back then also.

Note that this stunt was performed by a group of young aristocrats who went to Cambridge. At least one of the participants was nobility, another whose father was a well-known politician.

Imagine the same happening in the US today - a group of wealthy Harvard kids execute an embarrassing prank, one of whom comes from a famous industrialist family and the other the son of a major Washington figure.

The whole thing would be declared "youthful indiscretions" and no punishment of any substance would be handed out.

The more things change the more they stay the same. If you are wealthy and well-connected you can get away with damn well anything, and everyone else gets screwed.

</comment></comment><comment><USER12> If you haven't seen this before, I highly recommend the 8 minutes of video involved as a group of Australian comedians pretend to be the Canadian motorcade (carrying a special guest) during the 2007 APEC forum in Sydney.

[https://www.youtube.com/watch?v=ieb8QSpKhog](https://www.youtube.com/watch?v=ieb8QSpKhog)

[Edit: I had misremembered and thought that Canada didn't have a delegation at APEC...Turns out they just didn't have a delegation that was taxiing bin Laden.]

<comment><USER13> Canada is part of APEC.

Canada hosted the APEC meeting in 1997. The highlight of the meeting was the RCMP pepper-spraying students who were protesting Indonesia's government:

[http://www.cbc.ca/archives/categories/politics/civil- unrest/...](http://www.cbc.ca/archives/categories/politics/civil- unrest/general-27/1997-protest-and-pepper-spray-at-apec-conference.html)

</comment></comment><comment><USER14> Reminds me of the Yes Men:

[https://www.youtube.com/watch?v=9L9xPU_kJc0](https://www.youtube.com/watch?v=9L9xPU_kJc0)

[http://www.imdb.com/title/tt1352852/](http://www.imdb.com/title/tt1352852/)

</comment><comment><USER15> If people didn't lie the world would be a much simpler place. Lies for material gain we are mostly prepared for; lies for amusement, much less so. The _reaction_ to this sort of thing is less trust, more verification, less flexibility, and generally more difficulty for everyone, even those with legitimate call for resources (because now _everyone_ must verify that they need a VIP car, and the systems used for verification can fail).

Of course, lamenting the cost of lying is similar to lamenting gravity's affect on the impulse to fly - it doesn't really do any good. FWIW I think a modest fine and a brief (overnight) jail term was in order for the prank. Think of it as a small reminder that a hoax is not complete unless _you don 't get caught_.

</comment><comment><USER16> I don't get it, why is this on HN? I would like to understand how some irrelevant posts get traction? Please explain? Is it that the poster has 2K+ Karma?

<comment><USER17> It's an interesting post that appeals to our inquisitive nature.

<comment><USER18> Interesting in which sense? Even if I liked it, it is only humor and does not have nothing to do with "hackers". I'm not a better developper or I do not know what will help to launch a startup after reading this. Hacker News is not the Huffington Post.

<comment><USER19> It's an excellent example of hacking a social system, merely as a prank and with no damage to any individual, and follows a long history that goes back to MIT hacking ([http://hacks.mit.edu/](http://hacks.mit.edu/) and [http://www.catb.org/jargon/html/meaning-of- hack.html](http://www.catb.org/jargon/html/meaning-of-hack.html)).

In other words, it has a lot to do with "hackers" and is a very interesting and relevant piece of history. I agree it won't help you start your startup though; get back to building things and talking to people! :-)

<comment><USER9> Precisely I think that it shows you in a funny way, how far talking to people can take you.

</comment></comment></comment></comment></comment><comment><USER20> Interesting. Saw this on Reddit few mins back.</comment>


Ask HN: Please review my web app - <AUTHOR> http://map.pseudopattern.com/TileLayout.html?real=0.23&imag=0&m=2&n=1&colorparam=40&zoom=2&oldx=4&oldy=3

<comment><USER2> Neat. Might be faster and more scalable if you run it as Javascript on the browser. Although the current version seems to be fine also.

Here are some ideas on creating a business model around it.

(1) Let people order t-shirts with fractal patterns through Cafe Press. Set up the API calls so this use case happens seamlessly. Use Cafe Press or a similar fulfillment service. You make a percentage on each sale.

(2) Similarly, let people buy mugs, hats, visors, posters, playing cards, business cards, etc. with their favorite fractal graphics on them. Again use the same model as above.

(3) Produce images that are exactly the right size and format for screen backgrounds. Sell them or give them away. as wallpaper images.

<comment><AUTHOR> Thanks a lot for the ideas.

I'll have to do some benchmarking, but I doubt that javascript will be able to do this any faster. Each dot can take quite a few flops to get calculated. I would like to prototype a NaCl viewer though. I need to do some tricks to make the transitions smoother.</comment></comment>


Fexl – Highly robust functional evaluation - <AUTHOR> https://github.com/chkoreff/Fexl/tree/c0afb51878fe4277a75f88ad69a8086a5ce51644 <comment><AUTHOR> This version handles syntax errors, out of memory errors, and out of time errors, propagating them upward instead of halting with an error message, and reporting them in an orderly fashion at the end of the main program. Now the only calls to "die" are those which should never happen, i.e. they are pure assertions which are never expected to fail.

This allows for some very nice embedded calls to parsing and evaluation from within a Fexl program itself, which can always be expected to return to the caller instead of halting.

Ultimately I'm going to put a full-powered interpreter right on the web to allow arbitrary programs submitted from strangers, and this release is a necessary prerequisite for that.

<comment><USER2> Could you talk a little more about what `fexl` _is_? I don't see any obvious documentation beyond the README, which doesn't even seem to give a code sample; and, while 'functional evaluator' is an intriguing name, I don't know what it means.

<comment><AUTHOR> Fexl is a functional programming language. I used the term "functional evaluation" because Fexl evaluates functions.

Here are a few code samples:

[http://rosettacode.org/wiki/99_Bottles_of_Beer#Fexl](http://rosettacode.org/wiki/99_Bottles_of_Beer#Fexl)

[http://rosettacode.org/wiki/Fibonacci_sequence#Fexl](http://rosettacode.org/wiki/Fibonacci_sequence#Fexl)

[http://fexl.com/sample/](http://fexl.com/sample/)

This one's a bit more involved:

[http://fexl.com/demo/](http://fexl.com/demo/)

You'll also find some code samples in the "test" directory:

[https://github.com/chkoreff/Fexl/tree/master/src/test](https://github.com/chkoreff/Fexl/tree/master/src/test)

The program a1.fxl there is the definitive test suite. The program a2.fxl reads what you type and echoes it back.

The samples above should help illustrate the nature of the language. Grammatically, it's very simple:

[http://fexl.com/grammar/](http://fexl.com/grammar/)

For another quick illustration of the language, I'll give you a sample here:

        say "Hello"
        \x=(* 4.7 8.6)
        put "x = " put x nl

The output is:

        Hello
        x = 40.42</comment></comment></comment>


Ask HN: Should I fight back management enforcing Jira? - <AUTHOR> I'm a tech lead in a small shop (around 5 developers and growing) and our company has recently been acquired by a bigger one at the beginning of the year. We've been lucky so far as we've maintained independence of process and priorities. We've demonstrated times and times again that our development processes and our talent was order of magnitude superior to their existing dev teams.
Management from the head company is currently in the process of signing us up in Jira without consulting with us. Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex.
I'm close to the product owner so I can pull some strings there if this is a trap but I need to act fast. We've got nothing similar to Jira in place and are dealing with things without any dedicated tools, which means I'm open to learning Jira as I know our current methods will not scale. I'm worried for the following reasons :
- I haven't heard good things about Jira, especially on HN - I'm afraid it will only add more paper-filling work to my team (or myself) - I'm afraid they will use Jira to enforce a specific process to my team (I do not expect to have admin access to setup workflows properly)
Any thoughts on how I should handle this? <comment><USER2> Management has a concrete problem they want to solve:

"Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex."

So if you really don't want JIRA then offer an alternative that will meet those requirements.

Management may still say "just use JIRA". Before pushing back on this have a think about the cost/benefit ratio and whether this is really a battle worth fighting. You may lose credit with management, and more importantly, life is short. Arguing over issue systems is a stupid thing to spend your life on unless it's really going to save you a lot of time/frustration down the line. All in all, I would say it's unlikely that it's worth it.

<comment><USER3> To add to your coment, depending on the company, moving a lot of $$$ to capex is incredibly important for management.

If anything you should embrace Jira and look for ways to help get things classified as capex. Ask for a meeting with accounting/finance to fully understand it.

Just think of it as learning a new skill.

For the people saying to look for another solution, I would first figure out how much work they put in to selecting Jira. It was probably a big decision making process and you may be too late to make a change.

<comment><USER4> Unfortunately, this is a reality. I am part of a small team where we moved pretty fast.

We used to write our own stories in Jira and they were mostly one liners. They have now implemented so many required fields to fill out. Filing out one story might take 30 minutes.

And the management has implemented a mix of waterfall and agile methodology.

It is combination of worst of both worlds. We are asked to plan our next 10 or more sprints. Assign points to each story. And then we are asked to justify points to management. It is a big mess. In a week, we might spend 20+ hours on planning and planning to plan bullshit.

I fought this as much as I could. But in the end, I realized that this is losing battle. All we can do is work with them and help them justify their jobs and our jobs.

We have stories for planning stories. We have stories for reading documentation. We have stories for breaks. Oh I want to cry.

But good thing is if you work with system and make your team look super busy, you will get big bonuses and pay raises. Kind of like in real world, you can write the cleanest code but if you don't write features that customer want and brag about your product, you will not get paid for it.

<comment><USER2> > I fought this as much as I could.

I think that "fighting" this in the first place is not the correct approach. It would be better to "work on improve" it.

Perhaps I'm being pedantic, but I think it's an important difference, and creates a different (more constructive) mindset.

But yeah ... I've been where you are and I feel your pain :-(

</comment></comment></comment></comment><comment><USER5> I think you should grow up. I mean, what's your end game? Do you want to manage or own projects for the rest of your carrer, or do you want to move up and retire early? If the former, propose them a tool that you prefer and meets their requirements (maybe integrates with Jira?). If the latter, be the champion of Jira integration, get to know the new upper management who wants Jira in, explore how you can penetrate the structure of the bigger company, because right there is your opportunity - as, I assume, in your smaller company you almost hit the ceiling in terms of position advancement. Move up the ladder, earn more, retire earlier. What's the point of doing the same stuff 20 years down the line for probably just a little more money than inflation adjustment? Btw I used Jira sparsely for 10 years and it is not that bad. It's a matter of getting used to. Other more "cool" tools might look slicker but are often not that flexible.

<comment><USER6> No need to sling terms like "you should grow up". There's both a reason a big share of developers hate JIRA with a passion and also a reason business people like it. It's hard to find the fine line of it being useful for both parties and not just making the developers' lives harder and I've seen people having to spend an extra 30min per day just fighting the tool. This is not about whining to keep your independece, this is mostly valid criticism that it creates work instead of making life easier.

<comment><USER7> Indeed I could have spared the terms, but your comment is exactly what I am talking about: developers often place themselves agains business people, sometimes feel superiority, and are proud of it. But in fact it's wrong and immature – working in a company means cooperation, and both departments have experts in different skills. Another common pattern is to glorify tools and frameworks and be passionate about them. Again, why? It's not like being a github issues fanatic and hateful of jira makes any significant difference in the end. You say devs spend extra 30min per day fighting jira. For one, if they are as smart as they say they are, maybe the problem is not jira but between the chair and the keyboard. For two, say devs don't spend that extra time on jira. Who do you think will have to spend extra time to collect all the info necessary for the company to know what's going on? Probably the business owner. But who cares, devs want it easy. I wish luck to those who are very smart, because they will always find good work. I have hopes for all the others that they won't end up just typing code, because in some years time they may be replaced overnight by AI.

<comment><USER8> It's a matter of competing interests, and knowing your own domain best. Finance guys know finance best, devs know development best. Something (that looks) good financially might hurt development speed, iteration-time, bug- fixing, etc.

And it's not the CFO's job to know/understand these effects; its the CTO's job to. And it's the CTO's job to fight back on it if necessary, because its interfering with his domain. It's also the CTO's job to know whether or not its _actually_ interfering with his domain, and its his job to argue that position. And ofc, its the CEO's job to look at both offers, and decide whether or not the cost of interference to development is worth the benefits to the financials. With perhaps the CFO/CTO coming to an agreement independent of the CEO where trivial, as an optimization, but the ultimate responsibility is on the CEO's hands.

It is absolutely not about simple cooperation: its competitive cooperation. The goal is shared, but the steps to achieve it are not. And because of specialization, we cannot cooperate by simply knowing the global state of things, and determining the best course of action. We can only know the parts we know (a subset of the global state), and optimize our local interest in hopes that our local optimizations will take use closer to the global optimization. And _everyone_ is doing that, with a local view. The only person who truly intends to chase after the global optimization directly is the CEO.

You should be protecting your domain from competing interests, because everyone wants to have a say in your domain, whenever they can derive even minor benefits. They don't know the cost to your domain, or the benefits to it: they know the cost to _their_ domain, and the benefits to _their_ domain. They may have some _idea_ of it, but ultimately its your own job to know your own domain, and defend it as necessary.

Development does not, and should not, know whats best for finance, and the same is true vice-versa. It's not their position to. They specialize in their own domains, _and thats fine_. Obviously an overly-aggressive defense, or interference, can be harmful, but it'd be ultimately stupid, and likely harmful, to blindly follow the orders of people _who do not know your domain_ , in the spirit of cooperation.

</comment></comment></comment></comment><comment><USER9> The problem here is not the tool but the process that comes with it. From the managers in the bigger company's perspective integrating your team into the larger structure makes a lot of sense. What they are probably missing though is the impact that doing things their way is probably going to negatively impact your team.

Opposing the tool is not really going to get you anywhere. From the outside it will just look like you are resisting the integration with the bigger company and all the baggage that is going to come with not being "a team player".

For entertainment purposes only: fight fire with fire. Make a case for improving developer productivity by implementing a ticket quality score and use it as a metric. After all, the better the ticket the faster you can start work on the problem, rather than having to go chase down all the issues and requirements. Management will be rather annoyed at you flagging all their one sentence tickets as inadequate. As I said this is for entertainment purposes only. It's fun to make a point, but push quickly becomes shove.

<comment><USER10> I am always reminded of this story around throughput metrics for Software Engineering: [https://www.folklore.org/StoryView.py?story=Negative_2000_Li...](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

Your suggestion is delightful, and in a former company, one of our PMs, at a time when we were overwhelmed with requests, tried to tame the tied by requiring requesters fill out this simple template along the folloing lines (but I am paraphrasing): \- What is the impact on you/your team from this feature/bug not being addressed? \- What is the priority of this in comparison to other asks you have from the team? \- What is the impact to the business?

Even though the team did not like the bureaucratic approach, the number of requests went down dramatically.

</comment></comment><comment><USER11> I think you should embrace Jira but require that you get the access and permissions you think you need. Jira is not bad, but can be used in many ways, and when you figure out a way that works for you, it will not be a big deal.

<comment><USER12> Word. Solid advice. When you delegate all the decisions to a person looking at the global maxima at the expense of the local needs of your team you will not be happy with the results. For as long as you delegate this task, you will be unhappy with Jira. As soon as you take an active role, the perspective on Jira tends to change.

It's a good example of how being the change you seek changes your POV on something.

</comment></comment><comment><USER13> I think jira is terrible because it's complexity does the opposite of what you want management tools to do. It slows production to a crawl unless you invest heavily into change management and into building processes and training.

That being said, I think you'd be facing an impossible fight.

No developer loves these tools, and as a manager you hear complaints about almost everything imaginable, and if you have jira, and you think it's working for you, then it'll be hard to change your mind.

Leading upwards is really challenging, because you'll need to show the financial cost of using jira and present an alternative as well as a plan and a budget for how to get there if you want to convince your manager, and you're probably not paid to do that.

<comment><USER14> I know some orgs end up with crazy Jira processes, but after using it for 7 years in my last company it would be (or similar) the first thing I set up for company larger than 5 people.

We never used the workflows much, didn't go crazy with required fields, and didn't over analyze reports. It quickly expanded beyond the tech team. Each department created their own projects of their own accord and used them heavily. It saved a ton of emailing and left a record we could refer back to.

OP shouldn't have too much trouble mapping their current process to Jira unless they aren't organizing their work at all.

<comment><USER13> We use jira with around 10 different partners of ours. Where we buy software development on open source projects, but take code-base ownership and handle project management.

We use jira because it's what the companies use internally, and being in project management in the public sector with more than 500 it systems, well, we've been around a lot of tools and know how to adapt to them.

I've only seen jira utilised in a way that wasn't wasteful at one company though, and they'd spent a lot of time streamlining the way they used jira as well as how they wanted us to interact with them.

Every where else they would have done better with a white board and sticky notes, even though that's not something I'd really recommend either. The worst example was a company that had to assign their own project manager to everything because their developers didn't know how to label, move or even register things "correctly" in their own jira.

That's why I think jira is terrible, because it's designed to fail you miserably unless you spent resources beating it into submission.

Once you've beaten it into submission, however, it's a marvellous tool. I'm just not into that process, I want my technology to work out the box without customisation. That gives me less freedom, but I don't really care about freedom in "hour registration/planning" software, I simply want it to be as anonymous and easy going as possible with minimal effort.

</comment></comment></comment><comment><USER15> I've been at a company that used jira 5 different bad ways as they constantly churned through different ways of doing agile. I've also been at a company that used jira as a simple issue organizer with a handful of labels and literally nothing else.

It's just a tool that can be badly misused to make a bureaucratic mess, or can be barely used to write things down as we collectively think of them.

</comment><comment><USER16> We use Jira at work. We don't use it for everything.

This is how introducing Jira goes in a typical enterprise:

There's process, lots of it. There's training, scrum masters and Agile trainers flood the office floors. You can't move a task from in progress to done, because you didn't push the ticket through QA, QA Accepted, In Review, UAT and Waiting to be Deployed phases.

6 months later the Agile trainers are gone and sanity prevails and all the processes that don't make sense are quietly rolled back.

Thankfully you can configure Jira to do pretty much whatever you want, even the absolute minimum required to keep the dashboards management sees pretty.

</comment><comment><USER17> I'd encourage you to consider what they're truly trying to accomplish by using Jira. Are they simply trying to take existing agile processes and add new tooling? If so, that doesn't sound too bad. Perhaps cumbersome, but if new tooling allows you to keep existing processes then it's a win. But if using Jira is shorthand for changing processes, then those are what you want to focus on.

It sounds like you may want to talk with the product owner to really understand what the long-term goal of this change is. Then, if you don't like that, you'll be in a better position to argue why your current/alternative process allows you to provide more value to the company.

</comment><comment><USER18> To answer your concerns: 1) What you've heard is probably accurate. 2) It probably will add paper-filling work. 3) They will definitely enforce using Jira in _some_ kind of way, but not necessarily a strict way.

How you should handle this: acknowledge that it's just a complex tool, and like any complex tool, how you (and others) use it determines the experience. Yes, there will be an up-front cost to onboarding. But it doesn't have to go horribly.

As your team gets trained on it, you will probably quickly experience pain points. Document them and constantly measure the effect of them on your team's output. Implement workarounds as necessary and measure the effects. Provide the results to management along with your recommended fixes. In theory you should end up with 1) "We tried it your way, and this is how it went", 2) "Then we tried it our way, and this is how we improved it."

This provides a method to work around problems, and a solid argument to upper management to modify their use of the tool. Make sure the argument makes it clear that your changes are in line with the business's objectives, or probably nobody will care if it's painful for your team.

</comment><comment><USER19> Not a developer here, but a Jira user anyway.

I don't have dislike Jira that much, and quite frankly I think it does it job and doesn't get in the way that much.

I have to say that my team is larger than your, so maybe (maybe?) if you're only five developers then Jira might introduce a bit of process overhead? Or maybe once you have some process in place scaling to more developers will get easier?

It seems to me that the problem here is how you look at things: who brought your company clearly wants to scale you up. Imho you should see this Jira introduction as an opportunity for better scaling rather than a threat.

One little side note: if your company has been acquired then all the games are over (and I hope you made a shitload o money in the acquisition). Don't get too much in the way o management, otherwise it'll be just easier to get rid of you than to deal with you.

My two cents, I hope my options help.

</comment><comment><USER20> If the requirement is coming from accounting (qualification of spend as capex) there's no way to push back, but it also doesn't mean you need to follow the exact process of bigger company. You can negotiate minimum amount of documentation that for legal reasons your team needs to track in JIRA and do just that. Good luck!

<comment><USER21> Wouldn't that goal (qualification of spend as capex) be solved better by timecards? I don't see how a bug tracker helps unless you abuse it to be a timecard system.

Of course, timecard software can be awful too.

<comment><USER22> Jira has a field for time spent on a ticket, and can produce reports about it pretty quickly. There are also plugins available to let developers use various timers with it, or even integrate with timesheet tools like Harvest.

I've worked in a company that qualifies development time as capex. They can't just treat all developer butt-in-seat hours as capex. They have to allocate it to specific projects.

Using the issue tracker for that can streamline the process and saves the developer having to know which bucket to bill time against for each ticket, because the project manager or whoever can take responsibility for tagging each ticket with the appropriate accounting bucket.

And time spent on maintenance or meetings or peripheral tasks like interviewing candidates or configuring Jira goes into its own buckets that can't be capitalized. Using the issue tracker to track capitalizable time makes that delineation easy to enforce. If it's not in the issue tracker, it's not capitalizable.

</comment></comment></comment><comment><USER23> Jira can be pretty clunky and not great to use, but it gets the job done and really isn't that bad. I think it gets too much flak. A future product from a competitor will probably eat its lunch and eventually replace it someday, but if you just want to track different kinds of work, it works fine.

</comment><comment><USER24> My advice after working with Jira for the last several years: keep it light. Process heavy Jira is/can be a nightmare. Jira as "digital stickies" works well, and still provides plenty of metrics for outside stakeholders.

Based on my experience:

\- Use the "Jira Agile" (formerly greenhopper) add-on so that you have sprint/kanban boards and reports to visualize planned and in-flight work. Enable the "Backlog View" for your boards to separate planned from in-progress work.

\- Keep required fields to an _absolute minimum_ (we only require Summary) so that you can quickly capture cards and flesh them out later.

\- Avoid complex workflows - use the Software Simplified workflow if possible. Don't complicate it further without a really strong business case.

\- Learn the keyboard shortcuts. C (create), E (edit), I (assign to self) "[" (hide sidebar) and "." (command palette) are your friends

\- Confluence and Slack both have great integrations to let you publish and interact with your Jira issues

Those are just a few random thoughts on how we've kept Jira working for us and not against us.

</comment><comment><USER25> I wouldn't be worried about Jira so much, I'd be worried that management is going to implement New Processes to Keep an Eye on the developers.

Above a certain scale you kind of need an issue tracker, but when you're serving it instead of it serving you, it's the implementor's fault, not yours.

One of the reasons Jira comes up so much is that it's so customizable that it will merrily allow you to construct the most Byzantine nonsensical workflow you can think of, and fairly quickly too. It's not Jira's fault that someone told it to do so.

It really sounds like they couldn't find a manager capable of handling both teams, so they're going to throw technology at the problem instead of investing in their people to grow them into the position. It might work if they are willing to pivot quickly based on user feedback instead of just dropping New Process on you, but it's always slower to manage that way instead of just hiring a competent manager.

</comment><comment><USER26> My advice is to view this as an opportunity to improve the company's Jira workflow.

The status quo of issue tracking on your team is not scalable. And it's entirely reasonable that management should have a way to track your work. You are a small team in a big company and you're going to end up using whatever issue tracker everyone else uses.

You say that your team works better than others in the company. Tell management how your team's processes have resulted in high productivity and suggest improvements that other teams can benefit from. If using Jira hurts your team's productivity, find a way to quantify that -- ideally in terms of how the capex is higher than it needs to be because developers are wasting their time.

Recommend small, incremental changes rather than remodeling the entire system, and get other engineering teams on board with your proposals -- if the processes are bad, other teams are likely to want change too.

</comment><comment><USER27> The one place that I had to use Jira, it was poorly managed. The manager basically used it to create a list of every project and idea he could think of and then assigned quite a lot of them to me simultaneously.

The result for me was that I was overloaded with work. And then the manager became unavailable to discuss some important blocking items for about a week.

I am not saying that Jira or project management tools can't be helpful, but it does seem to have a tendency to encourage micromanagement as well as distracting from priority items with less important tasks and deemphasizing direct communication channels.

But of course management needs some way to know what is happening or that actual work is being done even, and a way to give direction about business goals.

I believe though that if not handled correctly this change could very well interfere with development. So you are right to be worried.

Personally I would do something like this:

1\. Very quitely make a backup plan for alternative employment. Just in case.

2\. Come up with an alternative to Jira that A) allows managers to to see that some development is even being done and they aren't just paying people to hang out and B) gives some details about what is being worked on. This could be just email notifications when people push to GitHub.

2b. I would also set up a weekly meeting with management to discuss dev progress and business priorities face to face. And as far as capex reporting maybe you can use a Google Docs with employee hours together with a dump of github commits, perhaps grouped by user.

3\. Explain that you want the dev team to focus on their work rather than checking off boxes for a process, and they want to stay focused on core tasks rather than a lot of small unimportant ones. And therefore since the current process is working you believe adding Jira will only take away time from core activities and make the team less productive in terms of actually meeting business goals.

<comment><USER12> Spin up a simple one board kanban project, use the new roadmaps in Jira cloud to show the epics to management and move things from backlog to in prog to done. Add tempo for time tracking if you need to show the accountants how much work has been done.

</comment></comment><comment><USER28> > _We 've demonstrated times and times again that our development processes > and our talent was order of magnitude superior to their existing dev teams._

That may be part of your problem right there. I'm sure your team is very good, but do you really think you are _10X_ better? It seems unlikely.

<comment><USER29> Order of magnitude (base 2)?

<comment><USER28> Now that is funny, thank you! :-)

But seriously, even when I've only thought I was _twice_ as good as someone else (and I'm afraid I have thought that too many times), it usually hasn't ended well.

<comment><USER30> I've worked for few different companies where some development groups were producing negative productivity, and others were producing positive productivity. Consider that one "profitable product ruined", and one "unprofitable product made profitable", or equivalent metrics.

What's the productivity ratio between -1 and +1? Is the first team "less productive" than the second team? Certainly. Is the second team "twice as productive" as the first team? I think the answer is "infinity", so "over twice" is a good summary for people who intuitively distrust "10x" as a number.

</comment></comment></comment></comment><comment><USER31> The majority of what I've heard at different workplaces about Jira has more to do with a) people not knowing how to use it and b) people not knowing and agreeing on how it was customized.

If the motivation is to track what the teams are doing, even if you win the fight on not using Jira, something will be proposed. Maybe it's Rally, maybe it's some POS that was sold because their sales guys and your CxO had a golf game.

You're better off ensuring that you could do what you need to do with Jira than anything else.

As an aside, I take issue with the term dev team - many people use Jira as part of an "agile" process, but they only plan things around development, but not test, only to find out later that their one liner change from dev could cause the tester a week to setup the environment for an automated test....

</comment><comment><USER32> Objectively, JIRA is buggy, slow, complicated, and hard to use. Unfortunately, it is also useful. Is it a good tool? No. Does it sometimes let you do things that you couldn't do before? Yes.

I would not choose to use it under basically any circumstances, but I also wouldn't be upset about being forced to use it - assuming I'm being paid well.

You should probably find out why they want to make the change. Is it just because your team is sticking out as being different? Is it because they want to try and do task efficiency calculations? Do they feel they don't have enough visibility into what you're working on? There might be a communication issue you need to fix (which JIRA probably will not address, even though they might expect so).

</comment><comment><USER33> It sounds like you haven't even looked at Jira, you are basing your view on HN comments. We use Jira productively, and progress is made visible across the entire broader team with it.

Of course, it can be used to implement inconvenient, useless processes as well.

</comment><comment><USER34> Don't base your judgement on software on HN. Jira is old and not the latest fancy tool: it's a battle hardened instrument that can be invaluable in the long run. But it needs to be used properly to bring out all its value.

Given you are a tech lead, this is the time to take ownership, create a Jira project and tailor its setup to your team needs.

Also, and this goes unsaid because Jira isn't new, the product has gone through many iterations of evolution and it's now a very nice UX. We use it for Kanban, Epics, Releases and the metrics help us visualize in an instant how efficient our team is.

If you give Jira a fair chance, you won't be disappointed.

</comment><comment> a-saleh Disclaimer: I actually like jira.

If I were you, I would primarily fight to have enough privileges to be able to have your own workflow. In that case, Jira can be maleable enough to make it fit your current process, and if you can negotiate to be the one that decides/implements the workflow, you should be able to shield your team from any rashly imposed process from above.

</comment><comment><USER35> I use Jira at work, and also at home for my side projects. At home it's little more than a self-hosted Trello instance. At work, it's more complex. Both do their jobs well enough.

Your problem is that you don't currently have any tools to track what your devs are doing. Your proof that you are "orders of magnitude superior" is nothing if you don't have the metrics to back it up.

If you accept that the larger company is going to want metrics on what your devs are doing (and that's an inevitability) then unless you have an alternative in mind and a compelling reason to use it instead of Jira, your best bet is to get on board, and do so with enthusiasm. If you're earnestly trying to use it, people will listen to the problems you run into and workflow changes you ask for. If you're complaining because you just don't want big brother watching you, you'll be ignored.

</comment><comment><USER36> What's your alternative tracking mechanism? And what does it report?

Truth is you might be so good because you're not at scale, they may be looking to scale you up which is great... you just have to get them the numbers.

Jira as a tool sucks dicks for pennies (trust me i've seen it)

Jira is however customisable as fuck, so if you're being forced into it then get admin! Stick to a simple workflow, basic practices. Jira falls short with the amount of munging people do to it, at the minute my team has a 9 column board with 5+ projects on it... that's not how it's meant to be done and it drags time out of my day.

So by all means if you're tracking already, demonstrate that (as long as it's not a damn spreadsheet). If you can't get them what they need then question why Jira. If you have to use it then get admin and make the tool work for your current process.

</comment><comment><USER37> probably the wrong thread to ask but what should a 5-10 person company with 20-25 outside contractors and lots of costumers that may need to access the issue use?

I'm currently consulting for a company who has no issue tracking system. they use an excel sheet which makes it impossible to have conversation about individual issue and nearly impossible to track updates.

I can't imagine getting them to spend $300+ a month for a managed system. bugzilla or Trac seem progammer oriented whereas this is a game dev company meaning copy/paste drag/drop image support is important (having to first create a local image file and then navigate to it is right out)

any solutions out there they could install on an unused computer or remote computer that might meet their needs or do they just have to be convinced to pay $4k+ a year?

<comment><USER18> The dumbest, cheapest, simplest option is e-mail. No matter who they are, if they're an actual company, they have to have an e-mail provider for their domain. This means (at the very least) they can create a single account that will accept e-mailed issues, and forward to all relevant users. Track the issue in e-mail thread replies, which always has the latest updates.

There may be provider-specific productivity features, such as G Suite's Collaborative Inbox, or Exchange's Public Folders. The IMAP Protocol also supports shared mailboxes, so any IMAP server that supports this will allow you to collaborate on issues sorted into folders that multiple users can access. Some open source mail servers definitely support it. Once they pick up a real issue tracking system it will probably support issues created via e-mail, so it can be seamlessly integrated later.

</comment></comment><comment><USER38> Bitrix24 is pretty good and free. They have a bunch of local domains, depending on where you want to have your data hosted. Ex:

[https://bitrix24.com](https://bitrix24.com) [https://bitrix24.eu](https://bitrix24.eu) [https://bitrix24.com.br](https://bitrix24.com.br) [https://bitrix24.in](https://bitrix24.in) [https://bitrix24.de](https://bitrix24.de) etc.

There are a couple things that are really good about Bitrix24. It's kind of like Jira+Confluence+Hipchat+Trello in one, but much easier use. Second, you have an option to choose between cloud and on-premise, just like with Jira.

</comment><comment><USER39> I have converted my team to Jira and Confluence. There is some initial learning curve, but if you select a subset of the features, and train / document how you expect each tool to be used, they will provide a net benefit to your team.

A friend of mine was at a company that was using JIRA, but they had no processes in place and ended up going back to using paper.

I think you really have to establish some simple processes to really get the benefit from these tools.

You can go overboard and try to require people to document every single detail every single day, but I think this is counterproductive. You have to find a balance.

</comment><comment><USER40> My team is in a somewhat similar position relative to our company. I like to think of Jira as an interface for management (and in our case, internal customers) to create and manage high-level requests and priorities. Then our team internally creates Trello cards for the actual tasks that need to be done because we find it significantly more efficient than Jira. On our current project, the ratio of Trello cards to Jira tickets is ~15.

As long as we also keep Jira reasonably current with the status of the project, Management's fine with however we want to track our work internally. YMMV.

</comment><comment><USER41> You can customize JIRA to fit your existing processes. Make sure you get the company to pay for that.

Embrace JIRA, it's like giving management an API into your team's performance.

</comment><comment><USER42> How do you manage projects now? Jira is fairly ubiquitous in agile development and has been used everywhere I have been in the last 5 years or so.

</comment><comment><USER43> If it makes you feel any better JIRA is probably the least shitty of the Atlassian suite products (not by a large factor). You might want to be more concerned about Confluence, BitBucket, and Bamboo creeping into your workflow. I'd suggest seeing if you can get away with using a more lightweight tool such as Github issues, Redmine, or Gitlab.

</comment><comment><USER44> Jira is fine - it's a complex tool and maybe slower than would be ideal, but they are really the only significant issues.

There are lots of positives, too - it is very flexible, and integrates with anything you want.

To be honest, I don't think there is anything nearly as good if you want beyond what Trello can do.

</comment><comment><USER45> Slightly offtopic: [https://www.neat.io/bee/](https://www.neat.io/bee/) Native FAST client for Jira.

The point is - once you make it works for you, life is great again. As others here said, be Jira master and climb the corporate ladder.

</comment><comment><USER46>
        We've got nothing similar to Jira in place and are dealing with things without any dedicated tools

Are you not tracking issues at all? I very frequently look up years old tickets to know why something is the way it is, and I could not imagine working without it.

<comment><USER47> That's what comments in code and project/product and technical documentation are for. Work tracking tickets should contain as little text as possible. Ideally the contents would be a brief 1-3 sentence description of the work, links to the relevant parts of the product/project and technical documentation, and whatever the definition of done is (e.g. "success measures", "acceptance criteria", and so on).

For normal work I simply don't allow my team to create tickets in JIRA unless there is at least a technical design document which contains at minimum a bullet-list describing the complete scope of work and some documentation or links to documentation regarding the specific requirements. For bugs I require the ticket created and put in our queue to be updated with the same material once the cause of error and the fix are identified.

</comment></comment><comment><USER12> Some companies treat their software teams like factory labor focusing on process and efficiency above all else.

I and most of us at Atlassian believe that epowering developers with more autonomy will drive better outcomes, better products, and better teams.

To help resolve these conflict, aspects of Jira needed to change and team culture needs to change.

To fix this we've been investing to democratize Jira's permissions model. We have been focusing on autonomy and flexibility to let any team design the way they want to work while giving administrators the power they need.

The SW biz is a very fast-growing space. When you combine massive growth, speed, and impact it is easy to lose control.

Feeling like you need tighter control means people often try to grip tighter. Sometimes that shows up in insanely complex and structured Jira instances. Sometimes Agile has become more important than agility. Sometimes using Jira has become more important to leaders than the outcomes the actual customer wants. This shouldn't be the case.

It can become easy to over-index on process and control at the expense of agility and software team autonomy. Don't do it!

This results in some over-designed Jira boards and workflows.

Leaders and managers in business and software development need to balance the desire for control with the need for S/W team autonomy. This endless dance between autonomy and control always shows up in every HN thread with detractors saying Jira sucks and fans saying Jira is great but the people setting it up must suck.

There is responsibility all around. Jira, for example, needed to improve the permission model to better empower teams with project level controls. We've needed to simplify the setup and clean up the issue views. These changes in Jira Cloud help admins feel more comfortable delegating more control to teams to design their own way of working.

We can't police how people use Jira in the wild but we can share our POV, our playbooks and we can make changes to the product to make it less likely that managers treat dev teams like factory labor focused on process and efficiency above all else.

A well-running team in a well designed Jira instance should work more like a lab than a factory.

Triads or squads should be able to chase a hypothesis, they should be better able to adapt to new information and respond to change than a factory assembly line. Leaders should be looking for more than process and efficiency out of the team and out of Jira.

How should you handle this?

Make Jira work for you.

Play a role in designing the way you want your team to work. Take the lead in changing the board design or the workflows when your work requires it.

The teams that make adapting to change their competitive advantage make the biggest impact on their company, their customers and the world. But, it takes trust and courage for leaders to create the conditions necessary for this. It means giving software teams a degree of autonomy and flexibility. Mastering this is the core competitive advantage for innovative companies today. These companies retain great talent, they hire great talent, they get great results.

Over the years we've heard the wishlist from Jira users and administrators in large companies and startups.

Make it easier to use and get started!

Give me flexibility and control when I need it!

Let my team design their own way of working!

To bring a new level of simplicity and power to Jira we needed to re-think the basics of the product. We also decided to open up and share our practices to go along with our tools (Team Playbooks [https://www.atlassian.com/team- playbook](https://www.atlassian.com/team-playbook)). We needed to learn a few things from the Trello team. We needed to think deeper than new features. The good news is that we've been doing that in a big way and you should be seeing that in the Jira Cloud product you can try today.

A couple examples

Project Level Permissions- Have you ever felt like the Jira you are using was designed for some other team or project? Alert! It might have been. Jira SW Cloud now makes it easy for next-gen project owners and team leads to design their own Jira projects, boards, and custom issue types without creating concerns that it will impact other projects.

Agile features can be turned on and off with the click of a button, so your team can customize to best suit its own unique workflow depending on its maturity level and the project at hand. For example, you can now flip between scrum and kanban methodologies in seconds

You can create issues and columns in-line, without ever leaving the board

Out-of-the-box team filters on every board, such as epic, issue owner, or labels make it easy for anyone to sort and filter in a click, no JQL needed.

You can define a rule to automatically update an issue's field or assignee based on the column it is moved into

You can display issue attachments as card cover images on the board

You can create, edit and delete issue types in independent projects

You can create issue types and customize the fields to suit your team's needs

We've got a lot more coming. The good news is that you can customize, modify, adapt and design Jira Cloud to do pretty much anything you want. The bad news is that means someone who doesn't know what you mean might do it for you if you don't participate.

Building software is complicated work. Jira's secret sauce is the way it simplifies the complexities of software development into manageable units of work that can be predictably shared and worked on by many different teams at the same time. Well designed Jira boards and Jira issues enable collaboration across increasingly diverse software teams that include design, marketing, analytics etc.(via integrations to the Jira issue)

That's a lot of text for a really small text box in HN. I'm trying to stay awake long enough to see the end of the Red Sox game. It's longer than that the typical bit of snark about Jira sucking or your admin sucking or doing work at work....sucking.

My advice:

You can have admin or project admin permissions, you can design the way your teams wants to work, you can integrate the tools like GH, BB, INvision, New Relic, Launch Darkly, etc that your team uses already. You can give the managers the vis they want and need and you can do it without sacrificing the sanity of your team day to day. And, you can use Jira to show whoever needs to know what you've been doing and how it impacts the business.

Jira should feel like the center of gravity that helps all the work your teams are doing hang together across different teams and tools.

</comment><comment><USER48> > We've demonstrated times and times again that our development processes and > our talent was order of magnitude superior to their existing dev teams.

i would love to read more about these "superior development processes" without any issue tracking or activities log.

</comment><comment> bra-ket jira is customizable, just cut some layers of default crap and it can be pretty simple and useful

</comment><comment><USER49> No need to worry about Jira. If you want to worry, worry about capex accounting... and even then, this is your managers problem, not yours. Also this is not a serious problem per se. It's about justification, mostly to financial auditors..

</comment><comment><USER50> So how do you track and manage issues now? You gotta use something. We can discuss JIRA against some other issue tracking tools, but I cannot imagine proper industrial software development without using any issue tracking at all

</comment><comment><USER51> If you are working locally then, IMHO, there's nothing better than a physical kanban board, our PM needs to 'manage upwards so they maintain a separate Jira for epics only.

</comment><comment><USER52> Jira is pretty cancerous. It will likely lead to hundreds of developer hours wasted on buggy, complex UI, new processes which are put in place because the features exist to support them, and eventually a slide into a multi-atlassian- product cluster of almost-working cruft.

That said you're SOL because you don't have a solid set of tools in place today. I know large, distributed teams who use github effectively for example and they have the processes and cultural inertia to make it work, but it doesn't sound like you've even got a solid home-grown alternative.

</comment><comment><USER53> JIRA gets a 5/10 from me. Interface is too much of the same colour for different information. Gets confusing when trying to move around quickly.

</comment><comment><USER54> I have used JIRA for years. It isn't perfect. Nothing is. But I have little to complain about.

</comment><comment><USER55> they optimise their company , you optimise your job? 1\. its their company its their money and how they want to spend it 2\. its your job you can try your best to make it easier or you can switch employers ?

</comment><comment><USER56> I dont think that there is anything wrong with Jira apart from the fact that it's slow. Other than that it has a lot of great features. I looked for an alternative for a long time, in my opinion nothing comes close to jira and it has only gotten better.

</comment><comment><USER57> I recommend try it - if you dont succumb you'll have immunity for the very long after that.

</comment><comment><USER58> _end goal being to be able to qualify this work as Capex_

This is a common piece of tax optimisation, basically if you say to the government "we did X hours R&D this year and here is the proof" they give the company some tax back. Of course it is pure coincidence that the word "development" has been overloaded in this way and you can get cash back for cranking out CRUD apps...

If that's the goal, you will not win this one.

</comment><comment><USER59> Theres nothing you can do. Just accept what management wants and do your job as best as you can</comment>


Google, please add NumPy to App Engine - <AUTHOR> http://code.google.com/p/googleappengine/issues/detail?id=190

<comment><USER2> In short: Don't hold your breath for numpy support on App Engine.

The news is that, a handful of people today began _commenting_ on the issue ("Please add NumPy [to Google App Engine]"), presumably because someone on some mailing list urged this action ([http://code.google.com/p/googleappengine/issues/detail?id=19...](http://code.google.com/p/googleappengine/issues/detail?id=190#c66)). Google mails all people that follow this issue whenever there is a comment, meaning that if you have voted for this issue you have ended up with ten "me too" emails in your inbox today. Which led to followup comments like this one: "Please stop to comment for nothing!!! It's spamming all of us (and sorry for this message) What is that pressure starring for one day now?? Are you all in the same team??"

Google has ignored this issue for over two years. They also ignored "No way to delete an application" (which sucked, given the small quota on App Engine applications you can build) for almost a year and a half ([http://code.google.com/p/googleappengine/issues/detail?id=33...](http://code.google.com/p/googleappengine/issues/detail?id=335&can=1&q=delete&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component)), despite 1000 votes and 100 comments. Deletion is clearly a simple fix, so you shouldn't assume that community requests would really sway Google.

<comment><USER3> You can delete an app.

<comment><USER2> Yes, but there was literally 1.5 years during which "No way to delete an application" was an open issue. And, unlike the numpy issue, you can't make the argument that "deleting an application" is a difficult feature to implement. Which is why it was so galling that "No way to delete an application" was open for so long, despite how many people were clamoring for it to be closed.</comment></comment></comment>


Partisan Divide Over Economic Outlook Worries Ben Bernanke - <AUTHOR> https://www.nytimes.com/2017/04/24/business/dealbook/partisan-divide-over-economic-outlook-worries-ben-bernanke.html <comment><USER2> I feel like no one here has read the article, and is just having their fun doing some character assassination.

      > "The election result completely reversed people's views
      > of the state of the economy. Republicans who thought that
      > we were in a dystopia now think things look great, and
      > Democrats, the opposite. And it shows that it isn't all
      > based on an objective assessment of the economy."

Seems a pretty salient and uncontroversial observation.

<comment><USER3> That's one thing that drives me crazy when I talk to people. When the other party does something they are outraged but when their own guy does it, it's suddenly OK. I guess the parties have achieved the final goal. People are not even capable of looking at a situation anymore and make up their mind. Instead they just blindly follow what they are being told.

<comment><USER4> I believe in a quite majority that is perfectly capable of independent thought and self-awareness, but lacking news outlets they trust to give them anything but narrative. It could be the slow death of newspapers that led us here.

<comment><USER3> The lack of newspapers they trust is just a consequence of political parties undermining that trust. You still can read the New York or Wall Street Journal and get enough information to form a reasonable opinion.

<comment><USER5> I disagree. Media seems to me to have gotten much more sensationalist and click baity over the last decade and often really stretches the facts in interests of agenda. To be fair maybe they feel this is necessary to survive in the face of the internet.

Trust is hard to establish but only takes an instant to break.

<comment><USER3> I agree that media has gotten more sensationalist. CNN for example is just horrible. But I would still say that it's not difficult to filter out real facts if you want to. Most people don't want to though.

<comment><USER5> Ya, true enough. Most people want to believe what they want to believe.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> It's impossible for economic policy to not be politicized. Look around the world, all political parties are distinctly grouped by their economic beliefs. If anything, the US political landscape needs to be more far more political on the economy. Differentiating republicans and democrats on their economic policies is almost impossible. Especially compared to literally every other country (excluding dictatorships). This almost identical belief about the economy has made an incredibly toxic and arbitrary system where people misplace their anger at each other because they have not been educated on what the true source of their anger is or what their alternatives are! It's made an ugly tribal political system where it's us vs them.

<comment><USER7> I agree. The economic policies of Democrats and Republicans is really indistinguishable from Goldman Sachs economic policy.

<comment><USER8> Private enterprises don't have economic policies.

<comment><USER7> You don't think private enterprises lobby for economic policy? Maybe you're just making an argument about wording?

<comment><USER8> Wording is important. The current US president is a good example of what happens, when one is careless with one's language.

GS doesn't define U.S. economic policy. It might lobby for some specific issues, sure. But it isn't interested in defining the entirety of economic policy.

Also, I don't see lobbying as a problem, if it is transparent.

<comment><USER7> Wording is important. And I intentionally worded my OP to convey my concern that US economic policy is indistinguishable from GS wishes. It's just a little artistic expression, and it was clearly effective since you apparently knew exactly what I meant. I'm not writing an article in the Quarterly Journal of Economics here. When US economic policy is indistinguishable from the wishes of GS, GS may as well have an economic policy.

<comment><USER8> What bothers me is the conspiracy-theory-like obsession with GS. No mention of JPM, or BofA, or Citi, and so on. It's not about you concretely, just in general what I often hear and see. Your comment was just an example of the focus.

It's like GS is the only bulge bracket bank with lobbying interests and deep Washington connections. GS are mostly smart and mean. Sure. But do you really think that their competition does nothing and lets them dictate their interests in DC willy-nilly?

<comment><USER7> It's because GS alum are consistently finding themselves in high political office. Rahm Emanuel, Obamas Chief of Staff, was on the GS payroll for $3k/mo while in office. His job description at GS was to "introduce us to people." Here's an article about GS ties to Trump's White House. [https://www.nytimes.com/2017/01/12/business/goldman-sachs- co...](https://www.nytimes.com/2017/01/12/business/goldman-sachs-completes- return-from-wilderness-to-the-white-house.html)

BofA, JPM, etc. definitely have ties, but it never seems to be as blatant as with GS.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> "You have to recognize realistically that A.I. is qualitatively different from an internal combustion engine in that it was always the case that human imagination, creativity, social interaction, those things were unique to humans and couldn't be replicated by machines," he said. "We are coming closer to the point where not only cashiers but surgeons might be at least partially replaced by A.I."

I think the politicians will finally get it when income tax revenues start eroding (maybe as soon as this year?). I'd expect this to force a pivot to a sales/transaction tax model. Hopefully (but I'm not optimistic) this is paired with a final capitulation on the necessity of a UBI.

</comment><comment><USER10> Quote from him ca 2006 - we haven't seen a nationwide housing bubble. Predicting is hard, even if you have tons of data. Greenspan used to take long hot baths (according to his book I read) to finalize the estimates. Guess what, he was really good at it.

<comment><AUTHOR> He said the same thing in his book "Courage to Act". I genuinely believed it until I read "The Short". You didn't have to have tons of data to predict the bubble, you just had to take the time to read the loans. Everyone saw this bubble long before Bernanke did.

<comment><USER11> Everybody saw the bubble, it made the cover of the Economist many times in the 4 years before the crash.

The hard part is predicting when and how it would pop, and nobody could do that. Tons of people lost their shirts shorting against the bubble. They weren't wrong, just early.

"The market can stay irrational longer than you can stay solvent" \- Keynes

The how was important -- everybody acknowledged that the market was in a bubble, but many people predicted that it wouldn't pop catastrophically as it did.

<comment><USER12> found it! [http://www.economist.com/node/4079027](http://www.economist.com/node/4079027) they def called that one. "Interest-only loans"

</comment></comment></comment></comment><comment><USER8> I feel a lot of commenters here don't differentiate between economics as subject of policy and economics as tool for politics.

</comment><comment><USER13> Economy has always been political, since thr discipline was founded as political economy, the part which modern economists have excised from their expertise. Good books on political economy include those by Ricardo, Smith, the excellent critique of political economy Capital by Marx and those books by Proudhon.

</comment><comment><USER14> Bernanke made the choice to resolve bad housing loans by handing out trillions (through the purchase of mortgage-backed securities) to the lenders instead of the borrowers. I think his analysis would be improved if he recognized that was a political decision, not just an economic one.

<comment><USER8> Not handing out, but lending out.

Bailing out households would be a far more political decision. The Fed could impose constraints on banks participating in TARP, to make sure the money gets paid back. The same wouldn't be possible to practically do with households.

<comment><USER15> In addition to the loans and direct investments in banks, there was a large asset purchase program:

[https://en.wikipedia.org/wiki/Public%E2%80%93Private_Investm...](https://en.wikipedia.org/wiki/Public%E2%80%93Private_Investment_Program_for_Legacy_Assets)

It can be cost neutral by way of selling the assets back to the market, but that isn't happening at any sort of rapid clip. The Fed currently has ~$1.8 trillion of mortgage backed securities.

[https://fred.stlouisfed.org/series/MBST](https://fred.stlouisfed.org/series/MBST)

The bailout targeted the entire economy. Imagine the pinch we'd be in if housing all of the sudden wasn't too expensive to buy (and thus not a glorious asset for all the people that have it).

<comment><USER8> Thank you for the insight! I haven't considered "sector targeting". 1.8 trillion USD MBS is a bit unsettling, I must say.

<comment><USER15> It's "only" about 12% of the market.

[https://www.federalreserve.gov/econresdata/releases/mortouts...](https://www.federalreserve.gov/econresdata/releases/mortoutstand/current.htm)

</comment></comment></comment></comment></comment><comment><USER16> "To Mr. Bernanke, when the economy — as well as the basic statistics that undergird it — becomes politicized, the result is bad policy. "A lot of the emotion is not really susceptible to nuanced policy arguments," he said, shaking his head."

Not the same! He didn't say that!

</comment><comment><USER17> He is correct in a way. As long as the government is trying to "control" the economy, it will be "politicized". The only way to not "politicize" the U.S. economy is to get rid of the Federal Reserve, etc.</comment>


Every software system used at Gitlab - <AUTHOR> https://about.gitlab.com/handbook/business-ops/tech-stack-applications/#tech-stack-applications <comment><USER2> I'm so sick of Gitlab support spam in every thread that mentions any issue, making it so that critical conversations are interrupted with self serving pitches!

>I once saw Gitlab do this thing.

>Hey, Bob from Gitlab thing here. We are really trying to make thing great for our customers . Our next release of thing will do foo which we hope will fix this. Here is a link to a marketing post comparing us to GitHub. Hope that helps. Please don't mention us in a comment, or I have to do this. It hurts to live.

<comment><USER3> Their CEO is the worst offender. Shows up on every gitlab thread with these generic/uninteresting comments.

<comment><USER2> The thing is - I get it. I thi k it's cool when people show up to talk about their product or code that is mentioned on a forum. It's endearing. But when it's systematized by a large corporation, it's no longer so.

</comment></comment></comment><comment><USER4> We've just had a bad experience with GitLab annual renewal, to the point where we didn't know if they'd cancelled our account or not.

The billing accounts system seems to be completely disconnected from user accounts. A notification banner was spammed to users in the GitLab.com user interface, saying that our account was going to be cancelled becuase we didn't have auto-renew. The users who got the banner didn't have permission to act on it in the billing system. The billing system said that we _were_ on track to renew, which disagreed with the banner. Eventually it transpired that the end- of-year "truing up" meant that our account was on hold, but we weren't notified of this.

And when we _did_ pay the bill we get a banner saying "you've been downgraded to the free plan" when the gitlab.com interface says we hadn't.

It really undermined confidence in how well these systems are connected.

On the flip side, the fact that everything is open meant that you can see customer support reps raising internal bugs about this stuff. The principle of open-everything makes it more pallatable, but it doesn't make up for lost confidence.

<comment><USER5> I am a product manager at GitLab and my focus is on making renewals as easy and pain-free as possible for customers. I am very sorry that you had such a confusing and frustrating experience here. We are working on a number of issues that will improve this process, including:

* Making Gitlab.com aware of who the payment owner is so we can more accurately target the renewal banner - [https://gitlab.com/gitlab-org/growth/product/-/issues/1551](https://gitlab.com/gitlab-org/growth/product/-/issues/1551)

* Updating the renewal banner copy for group owners that aren't payment owners so they don't attempt to renew if they do not have the right permissions - [https://gitlab.com/gitlab-org/growth/product/-/issues/1553](https://gitlab.com/gitlab-org/growth/product/-/issues/1553)

* Moving the renewal behavior from the customers portal into Gitlab.com so payment owners can more easily manage their subscription and renewal - [https://gitlab.com/gitlab-org/growth/product/-/issues/1528](https://gitlab.com/gitlab-org/growth/product/-/issues/1528)

* Adjusting how we do "true-ups" so they are done quarterly and pro-rated to the end of the subscription instead of in arrears - [https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/...](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1303)

I would love to chat with you to learn more about the challenges you experienced and to review some of our plans to make things better if you're up for it. You can reach me directly at mkarampalas[at]gitlab.com

<comment><USER4> Thanks, it's great to see that. Incremental true-ups would be very useful. My colleague is talking to an account manager directly, but I'll pass your message on.

</comment></comment></comment><comment><USER6> Gitlab has been pretty great so far, but the code review tooling is so poor I think I need to look elsewhere. The pull request pages take forever to load, they can't handle pull requests with over 800 lines well at all. It will collapse files with over 100-200 lines of changes for seemingly no reason (hiding the comments within them). You can't ignore whitespace in diffs, and the comments disappear from the diff if they push new commits, you need to look at them in the overview again.

<comment><USER7> I don't understand. This describes basically every code review tool I've ever used. If there's something aside from Gitlab that I should try that still integrates, I'd love to know.

<comment><USER8> For huge diffs, there's not much that beats `git checkout <branch> && git diff HEAD^`.

For leaving comments, pretty much every system I've used has issues. At work we use phabricator; the default settings are atrocious but they can be tuned to something workable.

I sometimes wonder how hard it would be to get diff reviews to be a first (or even second) class citizen of the git ecosystem. That way you can finally get the bliss of leaving review comments in the IDE. They already have "notes" which are vaguely similar, maybe it's something they're considering?

<comment><USER9> > _[git ecosystem] have "notes" which are vaguely similar, maybe it's > something they're considering?_

If you're referring to git-notes, they are ... kinda special. They are objects in their own namespace that reference the repository objects the notes themselves are attached to.

Sure enough, you can attach a note to any git-object. And you can view them either directly or from the git-log view. But the discoverability is lacking, and the UI of doing pretty much _anything_ with git-notes is absolutely atrocious. Because they are in their own namespace, you don't automatically get them when you do a pull or fetch, which can get pretty confusing.

For the curious ones, the magic invocation needed to pull in updates to notes from the remote repo is:

        git fetch origin +refs/notes/*:refs/notes/*

Notes are not versioned, and you certainly don't get nice N-way merges between local and remote content. Semantics are different from regular git, and stuff can get lost.

So from where I'm looking at things, git-notes are not suitable for plumbing in a code review flow.

<comment><USER8> You're right, I was referring to git-notes and they aren't suitable as plumbing for code review :)

I was meaning to point out that we've developed plumbing for objects with "weaker" guarantees than source code, which can still be attached to refs. To me, this is indicative that the maintainers are willing to accept patches on things that are outside the "core mission" of versioning source code, and might mean that they're open to the idea of accepting a well-architected code review feature.

Although, you're also right, in that there's still a lot of plumbing to make sure that authors can only edit their own comments, and that sort of thing. The more I think about it, there's a lot of work to be done and it isn't easy.

But, if you made a proposal, I think git-notes is precedent for them accepting your contributions. :)

</comment></comment></comment></comment></comment><comment><USER10> I don't know if any Gitlabbers are in the comments but I'd be interested to know: Is this basically your internal asset register open sourced?

I suppose they're not particularly top secret but there could be a version that has some more sensitive data and this is a safe derivative for example. Similarly, such an asset register would likely have non-technical assets as well while this just seems to be tangible, technical things?

I figure any large company with a risk management function will already have/need such a spreadsheet (or document), complete with some sort of data classifications to exist for auditing reasons so the interesting step is maintaining it out in the public.

Kudos to Gitlab for having the culture to allow this sort of stuff :)

<comment><USER11> Err, what is an internal asset register?

<comment><USER12> An asset register is how companies keep track of their assets. Any software license, computer, monitor, keyboard, copy machine, etc. the company claims as an asset is tracked in the register.

</comment></comment></comment><comment><USER13> And HN users only worry about "cloud lock-in". I've said dozens of times that the typical largish company is locked in to dozens of SAAS offerings that would be a major pain and expense to migrate away from.

Once you choose your infrastructure, you might as well go all in. Just look at their dependence on SalesForce.

</comment><comment><USER14> I used to love GitLab, and I still do in a lot of ways but I will no longer recommend them.

If you're looking for a shiny pretty interface for all your users, then Gitea can serve the same purpose. Personally, I find cgit to look fine too. I think GitLab simply tries to do too much, and they've built their entire app on a poorly scalable and bloated tech stack.

I think SourceHut probably provides the best platform for teaching developers a more native way to use Git that provides most of the same features as GitLab. For CI/CD there are so many better options outside of GitLab that integrate into Kubernetes and you won't regret it.

</comment><comment><USER15> Why is salesforce the center of attention?

<comment><USER16> Because it is the source of truth for all of your customers both current and future.

And surely customers should be the centre of everyone's business.

<comment><USER17> Like OP, I'd love to understand better what Salesforce does (so well, it seems).

Its a bit hard to imagine, just like SAP software (for me), since all your experience is on industries far from that world.

<comment><USER18> In their documentation Gitlab explains the usage they have of Salesforce, you may get a non-Gitlab specific view of it, for example: [https://about.gitlab.com/handbook/customer-success/using- sal...](https://about.gitlab.com/handbook/customer-success/using-salesforce- within-customer-success/)

</comment></comment></comment></comment><comment><USER19> Marketo eh? My wife mentioned wanting that in her small business after seeing a shiny video but I said the price is probably not going to be appropriate (some research seemed to support this). Does anyone have experience using it? I have mixed feelings about Adobe but don't know how much influence they wield.

<comment><USER20> If she wants to sell to enterprise Marketo is a good option because of the deal size / volume. Google uses it for selling Google Cloud Platform. Otherwise Hubspot is probably a better idea.

<comment><USER19> Enterprise is definitely not on the menu, and Hubspot or one of the similar alternatives does sound more around the level she'd need. I had some fun messing around with Mautic and it could be fun to learn, but I'm not sure how its future looks.

<comment><USER21> I'm not a Mautic user, but its future looks brighter now that they were acquired by the company behind Drupal.

[https://www.acquia.com/about-us/newsroom/press- releases/acqu...](https://www.acquia.com/about-us/newsroom/press- releases/acquia-acquires-mautic-to-deliver-first-ever-open-marketing-cloud)

<comment><USER19> Acquisitions can go both ways and apparently the guy who invented and put a lot of sweat into it (dbhurley) has parted ways with the project. Also they used to produce a lot of media on using it, but it's all a couple of years old now. Maybe that means they got the fundamentals right back then but it does send a mixed message. I would love to try it, I've set it up and it seems to be working, but I'm just not sure what'll happen if something goes wrong (their forum moves a little slow too). I have no special knowledge, just a gut feel and outsider impressions.

</comment></comment></comment></comment></comment><comment><USER22> I'm wondering where the GL is, for when we outgrow Xero (which was about six months ago).

<comment><USER10> This isn't a recommendation or advice but if you're after a ledger that's larger than what Xero can offer to a big org, Netsuite seems to be what Gitlab uses and is ironically enough also what Xero uses. Unfortunately (and somewhat ironically?) we're too big to actually have Xero run on Xero

<comment><USER22> If you'd like some feedback, for us it's less a volume issue and more a case of design limitations. We run subledgers per customer in our own code for clearing and settlement (we're a two-sided network), and posting the rollups back to Xero sometimes runs into edge cases and limitations. Recognition timing is one pain point, another is API-driven reconciliation.

What I'd struggle to give up is the ease of reporting. Xero's report designer is right in my sweet spot for usability, flexibility, and domain-specific correctness, probably my favourite reporting tool in three decades of shaking down business software.

<comment><USER10> Thanks for your feedback!

While I don't work on the product (directly) or speak in any official capacity, I can definitely route your pain points and compliments to the respective teams internally :)

</comment></comment></comment></comment><comment><USER23> Gracious. That's quite a lot to manage.

<comment><USER24> Doesn't seem that much for Gitlab's size. And they are doing an effort to document it all and write it down instead of having it lie distributed in the minds of employees managing those services.

</comment></comment><comment><USER25> I do find it a bit weird you released internal handles and employee names.

<comment><USER26> I was amazed to see they doxxed basically every admin they employ... Why bother securing any data when you can just publish it?

</comment></comment><comment><USER27> Surprisingly, does not look too messy

</comment><comment><USER28> Curious about whether Salesforce represents a single point of failure. If it goes down or is unavailable, what impact does that have on the rest of the organization?

<comment><USER29> In some architectures it can be, which is a risk. A while ago I was in a day long kick off for a project to replatform a division of a large company, with Salesforce at the core. As it happens, one of the other division's Saleforce instance was down the whole day, bringing down everything. Internal systems, web, sales... everything broken.

We listened to the lesson and the architecture we designed ended up not having Salesforce as a dependency for any critical or money producing customer facing functionality.

We used Alteryx as a ETL tool to keep Salesforce in sync in almost real time. The customer facing sites and services ran off their independent databases. This also meant that the developers working on that didn't need to know the details about how Salesforce worked, we just mapped Salesforce data to their database.

</comment></comment><comment><USER30> Surprised to see Shopify in the list (used for marketing?).

<comment><USER31> Yes, our web store for swag.

</comment></comment><comment><USER32> This is a great stack to learn from.

Does anybody know some other companies that have their business stack available?

</comment><comment><USER33> How did GitLab track and create this diagram? Is there a service that does it automatically?

<comment><USER34> See [https://app.diagrams.net/](https://app.diagrams.net/) \-- you'll recognize the style.

<comment><USER35> so that seems to be: [https://github.com/jgraph/drawio](https://github.com/jgraph/drawio)

</comment></comment></comment><comment><USER36> I notice that Nanoc, the static site generator they use for their docs pages, isn't mentioned there. Maybe it's just too small to matter?

</comment><comment><USER37> Very nice! Thank you for sharing, I wonder though, no fancy big-screen dashboard service in there? Do people not value that kind of thing?

<comment><USER38> They are a remote distributed team. I don't think their employees would value having to arrange their workspaces to accommodate a big screen set up high and at a distance from their workstation.

<comment><USER37> Dashboards are nice to have even on remote teams I think. Anyone can put up the dashboard or make a dashboard for their own screens if they wanted to.

</comment></comment></comment><comment><USER39> Nice, just curious counting the filled and dotted lines - how this software is integrated together?

</comment><comment><USER40> As a complete remote company, I wonder if GitLab's business affected much by COVID-19?

<comment><USER41> People still have kids who'd normally go to school, family to take care of, etc.

<comment><USER42> And there's the mental health and anxiety issues a pandemic and quarantine bring

</comment></comment></comment><comment><USER43> hmm.. something's missing. does the dev team itself not use any systems?? hard to believe

</comment><comment><USER44> Is Salesforce still a big things?

<comment><USER45> Gigantic and for dev jobs it pays extremely well for easy work.

</comment></comment><comment> mr-karan For a company that makes and promotes FOSS, their tech stack sure is dominated by proprietary SASS vendor lock in solutions.

<comment><USER16> As someone who has a B2B startup there is almost nothing in the open source space for Marketing/Sales Ops. And anything that does exist is really low quality.

And it's because (a) most developers aren't exposed to non-Engineering parts of the company so they have no understanding of what problem to solve and (b) it is incredibly lucrative to build a proprietary SaaS solution.

<comment> mr-karan > there is almost nothing in the open source space for Marketing/Sales Ops

There is [https://erpnext.com/](https://erpnext.com/) which is completely FOSS built on Frappe framework. If anything, it is rather higher quality than most SASS solutions out there.

<comment><USER46> It's not entirely clear on their website, but I assume the full software is at [https://github.com/frappe/erpnext](https://github.com/frappe/erpnext), and they have a model similar to Sentry?

</comment></comment></comment></comment><comment><USER47> s/This website uses cookies/This website got mugu'd by European policymakers/

</comment><comment><USER48> Funny how they don't seem to really have any non-specialised tools to coordinate, manage and track work in a structured way across the company (like smaller team tools like Trello, or larger ones like Asana). The only cross company collaboration tool I saw on that diagram was Slack!

<comment><USER49> Makes sense considering Gitlab _is_a cross-company collaboration tool; they eat their own dogfood. They have a whole set of features that compete directly with Trello/Asana

</comment></comment><comment><USER50> Wow, I didn't expect so much!

GitLab, here is my proposal: remove 80~90% of this. Keep the essential. Prove that you are a really innovative company. Stop following analytics. Engage with your users.

Prove that you can control entropy and recover your agility rather than going the bureaucratic enterprise software way, just waiting for a more hungry and foolish player to cut the grass under your feet.</comment>


Non-native event-driven windowing in Wallaroo - <AUTHOR> https://blog.wallaroolabs.com/2017/11/non-native-event-driven-windowing-in-wallaroo/ <comment><USER2> Hello! I'm the author of this blog post. Please feel free to reach out either here or on our IRC channel #wallaroo on Freenode.</comment>