In a nutshell, why do a lot of developers dislike Agile? - <AUTHOR> https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile/answer/Miles-English?srid=i5M8&share=1 <comment><USER2> The whole point of Agile was "people not processes" However because at my company we have professional scrum masters, everything must be religiously Agile.

This means that we must have a standup, everyday. we must have a retro, we must have planning.

almost half a day a week is lost to pointless meetings. I just want to get on with my job. Trust me to use the ticketing system to figure out what I'm doing and raising blocking issues.

<comment><USER3> When I was at (unnamed-giant-online-retailer) we had a big project for a while that resulted in having standups that had about a dozen people in them and lasted about 45 minutes to an hour typically. Every day.

My mind still boggles how nobody else questioned such a misuse of resources.

<comment><USER4> I was at (unnamed-giant-online-retailer) and a team of 12 too. Our rule is to speak with one foot standing so you have to speak fast... It takes 90 seconds per person usually, sometimes ending with "hey Dave, I need your help in X, let's talk it afterwards".

Same process run by different group will feel different.

<comment><USER5> > sometimes ending with "hey Dave, I need your help in X, let's talk it > afterwards"

Which means, given a 8 hours working day, that you've been needing the help of Dave since the previous day, for an average of 4 hours, and you _didn 't ask him yet_?

<comment><USER6> Strawman.

It's very possible the guy thought he could figure it out, but discovered he was wrong and mentioned it in the stand-up because it was the first opportunity that day to bring it up (remember, in a lot of places stand-up happens fairly early in the morning in order to give coders the largest block of contiguous time for development).

<comment><USER5> > but discovered he was wrong and mentioned it in the stand-up because it was > the first opportunity that day

Exactly. Which means that he's saying that at the standup not because of any special advantage given by it, but just because it's the very first appointment of the day. Had there been no standup, he would have asked for help anyway.

So either: 1) the standup covers up a fundamental malfunctioning of the team, namely that people can't communicate freely during the day, or 2) useful stuff that people say at the standup is stuff they would have said anyway at that time of the day.

</comment></comment></comment></comment></comment></comment><comment><USER7> What's ironic about this metaphor is that Agile's roots can be found in building construction. We all know the story of Toyota, but where did Toyota come up with the idea? From Japanese stone masons.

The nature of building with stone is such that you never truly know what resources you have to work with. The shape, color, texture of stone is all variable. This means too that the way each component fits together is unpredictable.

For the eye of a master builder, who constructs edifices with each relationship perfectly balanced, each component placed intentionally, who can see every step of the process and what each choice means for the integrity of the whole, such a craftsman understands that every day brings with it a whole new set of variable inputs, which can never be planned for, spec'ed out, or tasked to laborers who do not see the whole.

Modern construction cares nothing for such craft. It will be the domain of robots. Software development too will follow this path, as we humans are suckers for predictability. But such a road will be littered with people suffering in jobs that make them feel like robots, projects that fall flat, and endless repeating boxes of sameness.

<comment><USER8> Construction, it seems, is a "waterfall" by definition, and, it is, probably, from architecture the model took its roots.

Agile came from business and finance, where everything is uncertain and even not well understood.

<comment><USER9> As someone who studied the field, construction in abstract seems a waterfall model. Construction in practice requires something very similar to agile: too many uncontrolled real world variables, interdependent timelines, and sheer laws of physics.

If everything goes right, yes waterfall. Everything never goes right.

<comment><USER10> In rare circumstances everything must go right beforehand, e.g. the New Horizons probe to Pluto.

</comment></comment></comment></comment><comment><USER11> I'm a dev manager. We use agile, it works for us, and people are happy.

All you have to do is make a giant list of all the things to do, make sure people are working enough, and on the right things, and use the appropriate level of design -- sometimes a little, sometimes more.

I think the hardest thing is getting business stakeholders to get out of the "fixed project" mindset, though: here's what we want, here's how much money we have, how long will it take/how much will it cost? When the real question ought to be, what should we do first, given the budget that we have, that will most help the business?

Also, devs should be treated as adults. No "planning poker", forced daily stand-ups, or any of that nonsense. Just keep your stories updated in the issue-tracking system, deliver iteratively, and keep on shipping.

So much of what gets blamed on agile feels like bad org politics/poor stakeholder management.

</comment><comment><USER12> People hate Agile now for the same reasons people hated "extreme programming" before it: Mismanagement based on a few misunderstood buzzwords.

Extreme programming had the de-emphasis on documentation in favour of verbal communication, which got garbled into "just don't document anything".

Agile has sprints, which has been twisted into "crunch time every two weeks for two weeks".

<comment><USER13> And devops turns into "end user is QA"?

</comment></comment><comment><USER14> The problem with modern "Agile" and frankly all other software development methodologies is the mismatch between the knowledge and expectations of the business and tech. Business and tech tend to use Agile to keep each other at arms length and never learn about what the other does. This is a shame because originally agile was about forcing business and tech to work closely and interact regularly. Hence the short sprints and frequent stand ups.

In the parent example the management should have known enough about building to realize they were a creating a clusterfuck, and the builders should have had enough knowledge and input to the business to figure out what they were supposed to be building. When both sides assume the other is too stupid to work with and avoids meaningful interaction, it shouldn't be a surprise when the result is a hacked together mess.

<comment><USER15> The problem I've seen is rather than forcing the business and tech to understand and work with each other managers are hired to do 'agile' and basically proxy for the business. They don't know anything more than developers do, and while there is more iterative development, the feedback is coming from the wrong people. It just becomes useless meetings and checkboxes.

</comment></comment><comment><USER16> Alright, here's my Agile rant. It's bigger than my last one because I hadn't experienced it to its full potential.

In my current team, it's followed religiously. Stand-ups are daily and people use it as a time to fraternize between talking about actual work, I just want to get back to work. There's no camaraderie, every retro is this one guy bitching about how things aren't done the way they were in his previous job (and usually they aren't because it wouldn't make sense). The time between demo and sprint planning is a full day's of wasted time per developer, because there's nothing to do. Every developer writes hacks and things that shouldn't pass code review get passed because there's not enough time in the sprint to implement the known-good solution.

I've caught flak from going beyond the story requirements because I know what the final solution actually looks like. I also catch flak regularly because I run out of work and I take more tickets that are not in the sprint. I've never not finished a task when I did that. Every other meeting I get to hear a spiel from the project manager about how great Agile is.

I'm sure there's cases where Agile is the perfect solution. But it's not every time, and the rigidity that people want to apply was never meant to be there. I wish it would go away, but it's the perfect tool for management to be able to submit reports and say "look how consistent we are!"

<comment><USER17> So, it sounds like you hate your team, and agile just makes it more obvious.

So, here are the few quick fixes I see:

1\. point out in retro that standups as currently constructed are a waste of time. Tell them you will utilize the law of two feet if they can't be tightened up.

2\. Suggest a definition of done. If the product owner doesn't agree it meets requirements, code quality isn't high, and tests aren't there then _it 's' not fucking done._ That means your sprints are implementing too much.

3\. Don't pull in more work if other members are struggling to finish something. How can you help them out to make sure their code quality doesn't suffer? If your piece is adjacent to another that is in desperate need of refactoring/code quality improvement, just say that you needed to clean that up to implement your solution. Use that time to de-hackify.

<comment><USER16> 'Hate your team' is a little too strong, I think. I may dislike some of their working habits, and I think our code quality would be higher if we took code review seriously (I've been told to not hold back PR approval even on issues like not putting braces on single line if statements - if it runs, it's "good enough"; I'm also the only one to ever write tests). Implementing less isn't an option because we have a hard deadline

I see what you're saying in your last point, but on that particular sprint, someone didn't want to do something they had assigned to themselves and pulled in a different story/ticket. I have no issues picking up __anything __that is still unassigned, and I had mentioned during the daily that I was available if anyone needed help with anything. No one got back to me and I honestly didn 't know until later that day that the other story/ticket hadn't even been started. I don't think I should have to talk to individual developers to see if they need help; we're adults and if you can't manage your workload or can't communicate that then I don't have a solution for you

</comment></comment></comment><comment><USER18> Hi! Early Agile person here, but I hate what the term Agile has become. [1] I think there are a lot of good reasons to grumble about Agile, especially when management use it as a stick to beat developers. But I don't think the problem described here is one of them.

I think expecting business to know what they want is a mistake. When my dad was making software in the 60s, 70s, and 80s, we were mainly automating existing business process, so we could draft behind all the hard work done working out the right paper forms and reports. But modern software comes from a process of experimentation and discovery, competition and evolution. As the people who understand the technology best, we should be as part of that process from beginning to end.

This analogy is misleading because software gives us power that we don't have in the real world. If we start with port-a-potties and want real bathrooms, we just have to change the description of a bathroom and the computer will do the rest. In software, if you are disciplined about automated testing, refactoring, and keeping up with technical debt, an evolving architecture is totally doable.

I think where people fall down is that they don't believe that managers will give them enough time to keep things clean as they go. And I agree, they won't. You have to _take_ the time. But if you do it from day one you can do it gradually and incrementally. You can gradually redirect management pressure away from developers and toward making better product choices.

So please let's take control of our working conditions back. We're professionals, and we can say, "No, I'm still writing tests. That's a best practice, and it would be negligent for me to leave that out." But we can do that while delivering incrementally, so that no week goes by without the business getting some new benefit in production.

[1] [http://agilefocus.com/2011/02/21/agiles-second-chasm-and- how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell- in/)

<comment><USER19> _I think expecting business to know what they want is a mistake._

I'm not much of an agile true believer, but as a former developer who is now "management" (shudder), I have never-ending frustration when teams expect full, perfect, set-in-stone requirements from day 1. When you're developing a new product in a new field, that's not how it works. We have to build something that minimally works, get it in front of real customers, and then make adjustments based on their reaction. Lather, rinse, repeat. This isn't "management can't make up their minds." This is "management are not clairvoyant."

To those who hate requirements changes, I'd love to know how you are able to determine with 100% certainty the exact product the market wants before you build it. If you can do that consistently, you should be a billionaire.

If you do understand that we don't know for sure what needs to be built from the beginning, you have two options. First, I can give you my current best guess at what we need to build, and we can work together to figure out what the right starting point (mvp) is, with the understanding that the rest may change later. Or I can figure out the mvp myself, and only tell you that, preventing the situation in which I told you about something that later has to change, but also robbing you of the opportunity to see the big picture and contribute to the plan. Which do you prefer?

<comment><USER20> I think the main issue most devs struggle with is not the changing requirements but that the timelines are not adjusted accordingly and have to be swallowed by the dev with overtime. And in most cases when there is some adjustments it's not nearly enough to cover the actual costs. If that was somehow resolved I think the vast majority of devs would be fine with changing requirements. Problem is I don't think there is an easy way because most non- dev don't truly understand the costs involved.

Fr example can u imagine telling a plumber no the bathroom is now going to be 30 feet to the left. The plumber says ok but that will cost u a week of work. How many people would say no, u have 1 day to do it and u will be held accountable for my estimate and not ur estimate because I don't trust u when u say a week. Now assume the walls are closed and it's only after u open them u learn there are other issues. Doesn't matter, one day. This is what most de s deal with. I assume ur not like this but this is how most devs have to work. It's frustrating. If u would be given the week then u would be fine, but instead ur told the timeline and/or cost. U may even be told no u can't use those tools they r too expensive, but u need to complete the task in the faster then even people who can use the tools.

My whole point is it's often not the change requests that are the issue, it's what it entails, in that the schedule and costs are not adjusted fairly.

</comment></comment></comment><comment><USER21> It takes time away from real work without making that work significantly easier to accomplish. It is frequently used as a tool of control by managers who want to be in charge, thereby defeating its own reason for existence. The terms and practices tend to be hokey and faintly demeaning.

The problem is not the specific body of techniques used to schedule tasks and manage time; the problem is the way that the hierarchical nature of traditional management structures diminish agency and discourage transparent communication. This leads to misapplication of effort and destroys motivation, crippling productivity.

Empower people to act responsibly and they generally will. Exercise empathy and people will trust you. Give people the information they need and they will reciprocate. Agile development was an attempt at doing these things better, but it has been reduced to a collection of code words and empty rituals by managers who don't realize that it is actually their philosophy about the purpose and nature of management itself that needs to change, and not merely their choice of techniques.

</comment><comment><USER22> This somewhat mirrors my own experience with trying to practice Scrum: The spot where agile practices fail is invariably in management misunderstanding how it's supposed to work. Techies may get lost in bikeshedding every single user story, but it's management who hires Uncle Bob to come deliver a 1-week mandatory all hands training course and then doesn't bother to show up for it.

If they had, or if hey had bothered to read a book or something, then they would probably have seen that nice chart that's invariably somewhere close to slide (or page) 4 that lists all the things that $agile_process is and is not good for, accompanied by warnings about the need to be adaptable.

It's part of why I'm uncomfortable with name brand agile practices, because they make it way too easy for folks to interpret the guidelines as rules, or to interpret a useful tool as a silver bullet. For a while it bothered me so much that I was inclined to throw the baby out with the bathwater. I don't like to think that way anymore, though. Incompetent leadership will cause a team to be dysfunctional regardless of how it's organized. Blaming X or Y organizational technique for your boss's bad behavior is a gross misunderstanding of the situation.

<comment><USER23> > _If they had, or if hey had bothered to read a book or something_

Agile is simple, but it isn't easy at all. Without management buy-in to sit through the bikeshedding to find the technology gems among their technical talent's ideas (that they did a good job of recruiting and compensating, right?), Agile is going to turn into a swamp where mediocrities fool each other into thinking they are doing something.

Doing this while engaging low-bid outsourced implementation resources is 10X harder. Unless you pay through the nose for True Believers like ThoughtWorks, you're going to get fake Agile.

<comment><USER22> Oof, yeah. If what I've experienced is at all indicative, agile and outsourcing mix like nitroglycerin and shaking.

</comment></comment></comment><comment><USER24> This was very entertaining to read, and we all engage in these these analogies between software development and building houses or bridges or whatever. But nobody talks about this implication: the reason construction is so much more reliable and robust is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because nobody was insisting that all houses look alike and use the exact same materials. Since bits are easier to copy than atoms, we've made a fetish out of exact copying ("reuse"), and we peer-pressure each other to copy more with the complaint that they're "fragmenting" if they don't submit. I think it's _extremely_ silly. When something like Android starts feeling it's too fragmented, that's just a symptom of deeper issues, and force-upgrading everyone to the newest version just keeps us from better understanding the deeper issues.

Tl;dr - if you want software to be more reliable, insist less on reuse, and allow copies to diverge more.

<comment><USER13> Nah. buildings are alike because we have measured, tested and documented every damn material for their behaviors under various uses.

Thus if you want a wall of a certain size and shape, you have a list of materials to pick from depending on the weight is to carry.

The reason people insist on upgrading to the latest and "greatest" software is because there are no rigidity to APIs etc.

The Linux kernel gets more use than GNU/Linux user space because the kernel devs are held to a more stringent API rigidity. This makes kernel behavior predictable.

Similarly, Windows, for all its warts etc, gets used in business because Microsoft built a reputation for predictable APIs. Only with 64-bit Windows can you no longer run 16-bit binaries (dating back to Windows 3.0!), and that's because the 64 and 16 bit CPU modes are mutually exclusive.

</comment></comment><comment><USER25> It seems like all (pretty) good ideas, this one was meant as a set of guidelines to help teams build better software. That's until agile became a dogma (to some) and a means to an end in itself, with most the focus on getting agile 'right' and the project success being secondary. It's kinda like the idea of unions when they where first started to protect workers that were being exploited like farm animals. Nowadays some big unions could care less about the workers, and care more about their own survival as an entity and get trapped in activities which have nothing to do with their original mission. Of course, please don't see this exmaple as saying all unions are bad.

</comment><comment><USER26> Agile is for managing upward and a lot of developers would rather, you know, develop

</comment><comment><USER27> It's not just developers. My friend works in the sales department and he hates it. Every functional request that he make has to go through the usual "agile" process and it's just blocked by the weeks of sprints that are trying to keep up with the increasing backlog.

Some of those requests are very important and will benefit with actual real monetary results, but he has to personally escalate it through hierarchy and force dev team to break their sprint rules and force them to work on it.

In other words he has to make them be agile by force.

<comment><USER11> As a developer, it is highly upsetting to me when sales does this.

A well-functioning product development org has processes in place to decide what gets done first. These processes take into account tons of inputs including bug feedback, enhancement requests, potential for outages if something isn't fixed, long- and short-term competitive and strategic concerns, customer requests, and internally-sourced architecture requests.

Then some selfish jackass comes along (from whatever department) who just _can 't wait_ because WE NEED TO GET THIS DEAL, so the entire process is thrown out the window to satisfy the whims of one customer, who may not even be large, high-revenue, or strategically important, and the wrong works gets done.

Please, stop the madness. Don't go around the product team, and if you're in eng, please don't tolerate this bad behavior.

<comment><USER28> Fuck those people. Sales that are that pathological are all kinds of broken.

</comment></comment></comment><comment><USER29> Probably an essential mistake is to put multiple people to work on a greenfield project at once, when the requirements are particularly uncertain.

Better to allocate a single full-stack dev to experiment for a couple weeks. He also will interact with the business owner daily. Let him focus on the business logic and also the core user interactions.

On top of that MVP foundation (i.e. on week 3), you can put the rest of the team to refine backend, frontend, graphic design and so on.

<comment><USER30> > Probably an essential mistake is to put multiple people to work on a > greenfield project at once, when the requirements are particularly > uncertain.

This statement rings so true to me that I really hope there exists a fleshed out version of this theory, with examples to prove it and maybe a catchy name, etc.

Where I am now, I've literally participated in an identical thing being built in two ways at two different times:

\- The first time, I was the initial full-stack dev, along with one other guy (we were more of a duo... we paired a lot and worked pretty fluidly, it was kind of a 2-person equivalent of a single-person experiment.) The result was finished in 3 weeks and was flimsy but cohesive. Eventually the team was reduced to just me and I carried out the project for a few more months before a proper "team" was on board.

\- Then, the company noticed what we had done, decided that a bunch of other people had done similar things (it's a large company, after all), and then a _250-person organization_ was formed to write an MVP that was largely identical in scope. I wasn't in any leadership position in this new org, so nobody really cared that I had experience in this. I was reduced to writing a tiny insignificant part of the larger whole while our director drove the requirements. We're 10 months in and haven't shipped the first milestone yet.

In the first example, we were almost _too_ successful. The resulting product was used by thousands of people, for important things, with a lot of satisfaction and kudos from the users. But the total size of the team never really exceeded 5-10 people, so it got to the point where we were burned out supporting it, and there weren't enough reserves to call in to help because of the "second system" distracting everyone:

In the second case, we don't have our first customer yet (although we've only kind of "soft" launched.) We did a massively half-assed attempt at agile that was basically "waterfall, but more vague, and please work harder", where we kinda half-assed came up with requirements, split everything up into 10-15 major "tentpoles", each of which was developed by separate teams. 6 months later we decided to start "integrating" all of it. 4 months after that, things finally kinda sorta work end-to-end.

I've gone through a ton of self doubt through the process. In the first case, it worked only because there was almost no communication: we just did what we felt like, explored, and we were lucky that the end result worked. "Clearly, this will never scale, and is no way to run a _real_ software product", I remember thinking.

When the org got huge and we did our second system, I thought "Finally, I can learn to do what real software devs do and work for a big team with communication and requirements, etc". And inevitably when the result is a big pile of shit, I can't shake the feeling "this would've been better if I knew how to do real software development and work with a large team." Self loathing ensues.

So I witnessed the pendulum swing each way. The first way was massively successful, but I suspect isn't sustainable (the product is withering due to lack of support now.) The second isn't successful at all, and is a complete mess, but maybe it'll be better with time.

The only thing I know for sure is that few companies in the world can afford the amount of wasted time and energy we've spent on the second system. I suspect the real world works more like the first case but I don't have enough experience to know. I can't shake the thoughts of "I haven't seen real software development yet", and I don't know how much validity there is behind those doubts.

<comment><USER17> > Our highest priority is to satisfy the customer through early and continuous > delivery of valuable software.

> Deliver working software frequently, from a couple of weeks to a couple of > months, with a preference to the shorter timescale.

[http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html)

It sounds like the system started off as agile and the second system lost the plot.

</comment></comment></comment><comment><USER31> Paraphrasing a comment on /r/programming about this yesterday: If there is a decent set of requirements, then the framework used is irrelevant.

<comment><USER12> But Agile, as I understand it at least, is explicitly designed for cases when requirements _aren 't_ fully known.

<comment><USER32> Agile is designed for that case, but most development methodologies are designed for that case.

The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles.

Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects.

Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.

<comment><USER12> > but most development methodologies are designed for that case

Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product.

It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.

</comment></comment></comment></comment><comment><USER33> I think a lot of commenters here are missing the point being made in the short story.

Agile is good for startups building a product where they don't already have a known product/market fit. It's understandable in that situation.

A client of mine uses it to unburden itself with upfront design for a 3rd gen system that is well known and could easily be built with waterfall. There have been (what I would call) two false starts already. I don't see why agile is beneficial in this situation.

</comment><comment><USER34> Agile is used to justify both rigidity as well as chaos. The one hour standups and forced sprint metrics are on one side. The utter lack of planning that is waved away by claiming agility is the other. These are two extremes, and the word seems to fit both the bills depending on who is doing the complaining.

</comment><comment><USER35> While well intentioned as an abstract concept, all discussions around agile as a business concept to me inevitably lead me to conclude that agile sits somewhere between a cult and a cargo cult and that anyone drinking that kool- aid will at some point in the discussion run across no true Scotsman fallacies.

</comment><comment><USER36> I see the benefits with agile, but I cant help feeling that something is lost in a process that so completely controls the employees ... it is probably great to churn out good software, I doubt however that great software happens in that environment

</comment><comment><USER37> _So we just bought a port-a-potty, and screwed around on the internet for two weeks._

It seems to me, the there problem isn't agility, it's a lack of professionalism.

</comment><comment><USER38> Agile is supposed to be a development process, not a business process, but I've never seen it implemented that way.

</comment><comment><USER39> It's kind of like communism. Seems great on paper, but it just never really plays out effectively.

</comment><comment><USER40> Agile, IMHO, was meant to be a sort of zen-like "process-less process". After a few decades it became understood that software development wasn't working and doubling down on borrowed traditional engineering practices wasn't resulting in better software, only incredible delays in delivering broken software.

Here's the manifesto:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

 _Individuals and interactions_ over processes and tools _Working software_ over comprehensive documentation _Customer collaboration_ over contract negotiation _Responding to change_ over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

This is deep stuff and an incredible (and rare) set of pragmatic philosophies set down by folks who'd been suffering through the industry for a while.

Processes are intended to minimize risk and ensure reproduction of already achieved work. If you aren't making yet another copy of something that already exists, you don't want a process.

(sorry if this comes off a little braggardly), I've been known to run incredibly effective teams that produce tons of work very quickly. I use what I call an "Agile-ish" approach based on some personal meditations on getting software done. I call this approach the "Get Shit Done" model.

1) Is this new work or reproduction of old work (should I explore and evolve or reproduce?)

2) If this is new work, the goals are set down as very coarse milestones with exit ramps in case things are working out.

3) If this is new work, work is broken down into a check-list in a pipeline with the following steps: To Do->Doing->Paused->Done

Work is first filed as tickets in To Do. When it's being worked on it moves along to Doing. If, during "Doing", new work is identified, it's created and put into "To Do". If necessary the current work that's "blocked" is simply moved into "paused".

Once Paused work is unblocked, it moved back into "Doing". It either finished, creates new work tasks or is paused again. Rinse and repeat.

Kanban boards work pretty well for this, but you can do it with a spreadsheet in a pinch just fine.

4) If this is new work, work is only considered "Done" if it's checked in, tested and documented (and builds). Everybody hates it when they're doing it, everybody loves it when they need to figure something out later and the customers drool over getting rapid delivery of already documented, tested and validated stuff.

This scales pretty well for teams of 1-to-100 (but starts to strain on the larger sizes).

Teams are organized into hierarchies each with their own pipelines. Each team has a team-lead. I meet once a week with all the team leads and require all team leads to meet with their teams once a week. During crunches or abnormal events, we meet more often. This creates a cascading "clock" that identifies things that are taking too long and might need extra attention. I give team leads extraordinary autonomy to figure out the details at their level. This also gives people a week to be create and figure out ways around issues and problems. Team members can generally float or matrix if needed. Work moves along a general "discover, productionize, deploy" model.

What's amazing about software is that it's almost always new work. If it's not new work, you still don't really need a process to reproduce it. Just copy the code into the new place, configure it and start it up. This is unlike any other engineering endeavor in human history and it takes entirely new ways of thinking to get it done.

What I've found is that many many organization simply want to repurpose waterfall models and apply "Agile" sounding names to everything. I once turned down work because the customer had a 500+ page manual on their formal "Agile Software Process Methodology". No, no, _no_ , NO. You don't _get_ it.

Here's another protip: Sprints are for engineering, Kanban is for Research. If you know what you are doing, use Sprints to force a development clock. If you don't know what you are doing and need to figure it out, Sprints just make everybody angry and create useless artificial pressure that accomplished nothing. If you're engineering, you already know what to do, Sprints help provide motivational energy.

</comment><comment><USER3> Agile is just a collection of stuff that people put together in order to ensure useful productivity from arbitrary teams. Often it's misapplied and misused, usually in order to micromanage.

The roots of agile come from the bad old days when the typical software project was a consulting gig with an elaborate negotiated spec and schedule and a huge disconnect between the buyers and the developers, let alone the users. And when the "software crisis" was in full swing, and many software projects failed to deliver anything of use, at all. Back in the days when even using source control wasn't common, and when regular builds and smoke tests were even rarer.

Agile ensures a few things:

It ensures that you use an incremental development strategy: start with something simple that works, then iteratively add to it over the course of short periods of work to move it closer to the desired state of functionality and capability. Because you routinely have workable builds this means you will always have _something_ to show for your work at the end, because you have a pattern of having something working all the time.

It pushes the team toward continuous integration and regular builds with testing. Which avoids building up invisible technical debt due to undone integration work as the project progresses. Agile avoids the "big bang integration" problem.

It pushes the team toward visibility and interaction, so they get to know what everyone else is working on and it forces collaboration related to integration ASAP, all of which helps increase team cohesion and leads to higher code quality. People get to see the products of other's work routinely, making it easier to see what they're good at (and not) and aiding team mates in learning from one another.

It avoids unnecessary over-complications and the tendency to procrastinate, such as the notorious "second system effect". It ensures that people stay concentrated on _real_ milestones and _real_ work not pie in the sky perfect systems with schedule estimates off by orders of magnitude or not even feasibly possible.

It gives the "stakeholders" more visibility into the work. The product itself becomes the ground truth for the product, rather than a spec or a memo or a contract. If those folks have concerns they can be addressed and taken care of before it is extremely costly to fix. And if they want to make changes to the design relative to their initial thoughts, that too can be done fairly easily, resulting in an end product that is more suitable than would be the case otherwise.

And it ensures that sprint by sprint, work gets done, the product moves forward. With good teams this isn't a problem, but in the "enterprise trenches" with demotivated teams of average or below average coders this can be a real problem. It can be difficult to get anything done, let alone anything more than just spinning their wheels.

All of these things are for the most part good things, and they are the reason why the concept of agile has become so pervasive. The problem is that today a lot of the agile basics just go without saying (continuous integration, routine builds and testing, iterative development, short sprints for work, and so on) while some of the other aspects end up being applied in a cargo cult manner with no comprehension for why they were used as well as when they are warranted and when not.

Even if agile practices were being used correctly most of the time, which they aren't, it still would not be a good one size fits all practice for all circumstances. Moreover, the modern perversions of agile have done a lot of damage. Removing opportunities for use of initiative, creativity, and expertise by many coders, taking responsibility for even the tiniest decision out of their hands and transforming them into children. In some ways agile is like a remedial course in software engineering, but a lot of high caliber developers are finding themselves stuck with it even though it is restrictive and harmful, because management is thoughtless.

</comment><comment><USER41> Agile, like anything, is perfect when you implement it perfectly. Nobody does, but it's not the method's fault, the method is perfect. What I have seen is it used as a chip on the shoulders that makes product meetings feel like dealing with communist border guards.

Working in Agile shops can be a lot like watching lab mice running a maze. You try to say, "hey, so this path you are working on, there is a map for it when it was solved in <discipline x>." and the response was, "this is Agile, we don't take grand designs or waterfall requirements, and we don't need anymore chickens in our standup."

Or you say, "hey, so this thing you are building, for someone to buy it, we're going to have to explain to them why it's good and how it meets their expectations, can we create a sequence diagram or a model so I can plug in how it meets standards and regulations and code and such?" and the response is, "we don't need documentation, the code is documented, and if you had provided us with the requirements we could prove it in our unit testing."

The trouble I have with a lot of engineering and dev culture is what it lacks, and often irrationally rejects, is balancing the technical understanding with a top down view. The best engineers have or at least appreciate this, and they bring it with them. Unfortunately this gets them immediately promoted to roles where they aren't actually writing code.

I've used this house building simile in Agile shops before, where any bunch of carpenters, electricians, plumbers and brick layers can build a fine house that will stand up, but the matter of whether anyone will want to live in it, buy it, insure it, legally sell it, live anywhere near it, or trust that it won't be knocked down by local climate or regulations - is an equally complex problem you need someone with expertise to solve.

Everyone has complains, devs about managers, managers about devs, it's an age old problem. A lot of Agile gets used to formalize an adolescent culture. I look forward to the pendulum swinging back to a more balanced equilibrium.

<comment><USER42> This is a frustration I had in my most recent project. Management did a good job of coming up with interesting features in the abstract, but a terrible one of communicating those features and working them into the app in a way that was intuitive. I often found myself saying, "this is potentially a good feature, but how do we explain it?"

We never had a good designer on staff, so that was a huge part of the problem. A couple times we used outside designers but they didn't have a holistic view of the app, so their designs created as many questions as they answered.

</comment></comment><comment><USER8> Because the way you manage an orchestra does not eliminate the necessity of each musician to be able to perform decently?

</comment><comment><USER43> The moment the process becomes a goal instead of solution - now you have two problems.

You cannot abstract away the need for common sense.

</comment><comment><USER44> Listen to one of the authors of the manifesto itself: [https://www.youtube.com/watch?v=a-BOSpxYJ9M](https://www.youtube.com/watch?v=a-BOSpxYJ9M)

(BTW, he is very opposed to the use of Agile as a noun ;).</comment>


Indian govt may shut down Blackberry operations in India - <AUTHOR> http://www.thehindu.com/business/companies/article538467.ece

<comment><USER2> Sensationalist title, blech.

The new meta-monitoring rules they are being asked to comply with are the same for everyone.</comment>


How America's Broken Meritocracy Drives Our National Anxiety Epidemic  - <AUTHOR> http://www.theatlantic.com/health/archive/2012/07/trickle-down-distress-how-americas-broken-meritocracy-drives-our-national-anxiety-epidemic/259383/

<comment><USER2> The term "meritocracy" is one of those annoying words that appears to have a current common usage that is almost the opposite of what its originator actually meant.

Michael Young, in his satirical essay _The Rise of the Meritocracy_ was actually warning about a managerial style where people are promoted based on a definition of "merit" that is exclusive and self-serving for those currently in power and _not_ based on actual objective performance. Anyone who has had any contact with long-established bureaucracies (e.g. the UK Civil Service) will recognise this kind of "meritocracy".

Here is Michael Young righting fairly recently on the topic:

<http://www.guardian.co.uk/politics/2001/jun/29/comment>

It's worth noting that the Wikipedia page on meritocracy describes Young's essay as:

" _The essay was based upon the tendency of the then-current governments in their striving towards intelligence to ignore shortcomings and upon the failure of education systems to correctly utilize gifted and talented members within their societies._ "

<http://en.wikipedia.org/wiki/Meritocracy>

</comment><comment><USER3> I see what the author is getting at and agree. However we need to analyze this statement... "Far more important, he argues, is debunking the myth of meritocracy, harmful 'because it provides an incomplete explanation for success and failure, often mistakenly exalting the rich and condemning the poor.'"

It's important for people on the one hand to not feel too terrible if they don't achieve their dreams. But it's also important that people not become so self-obsessed with the impossibility of dreaming that we stop dreaming to begin with. There are people who always have a reason for why something didn't work out... you know those kinds of people. They never achieve their dreams. They've doomed themselves from the start.

We need to find a way to be a less anxious society that can still dream and accept failure.

</comment><comment><USER4> Interesting article, but one quote from the sociologist was way off the mark:

"The historical decline in self-employment and the concomitant rise and dominance of large oligarchic corporations (including chains and franchises) have created barriers of entry for starting and sustaining small businesses and sharply reduced the entrepreneurial path to mobility."

I don't know what time period he's talking about, but self-employment has grown dramatically in the US between 1969-2006, by about ~244% <http://en.wikipedia.org/wiki/Self-employment>

<comment><USER5> I think what he means by 'historical decline' is that in centuries past the vast majority of people were either farmers or what would be considered small business owners. Only around the time of the industrial revolution did there start to be mass employers in the private sector.

Also it's probably a bit misleading to throw out the 244% statistic without giving the overall relation of self-employment to regular employment.

"In relative terms, the share of self-employed within the labor force grew from 14% in 1969 to 21% in 2006 in metropolitan counties, and from 11% to 19% in non-metropolitan counties."

So while there has been a 244% growth, the self-employed still make up around 1/5 of the total work force. Historically I'd assume more than 60-80% of the work force would have been considered self-employed. Ignoring certain circumstances such as slavery, the only historical mass employers would likely be governments/military. Perhaps in times of war a large portion of the work force would be conscripted into military service, but most of the time the majority of the population would be farmers or local tradesmen.

<comment><USER4> Agreed about the 244% - apologies. I glossed over the relative part which is kind of important here. There's still been growth, but it hasn't been that dramatic.

</comment></comment></comment><comment><USER6> The article claims that the US is "near the bottom in terms of actual social mobility", but only supports this with some points about how social mobility in the US isn't that good.

The US is still one of the most meritocratic countries in the world.

<comment><USER5> >The article claims that the US is "near the bottom in terms of actual social mobility", but only supports this with some points about how social mobility in the US isn't that good.

They clearly reference several books by the people quoted in the article. I assume that their claims are quite thoroughly discussed within said books. You may not believe or agree with them, but it's not as though they are pulling them from nowhere, sort of like this:

>The US is still one of the most meritocratic countries in the world.

And you base this claim on...?

</comment></comment><comment><USER7> Quoted from the article, Obama's father and mother "passed some excellent genes to the current president."

I don't think the author knows what "meritocracy" means. Someone with good genes "making it" is what a meritocracy is.

<comment><USER8> He continues with "An April 2012 report out of UCLA provides further evidence that DNA determines intelligence, to a large extent"

And if you agree that intelligence is a large enabler of merit (I don't), then the connection between genes and meritocracy is blurred enough that you might be able to argue that good genes is correlated with more merit, or at least a larger potential for merit.

</comment></comment><comment><USER9> It's getting so that I'm running out of snarky things to say about some of these God-awful Atlantic pieces that keep showing up on HN. They're like cockroaches.

 _...In other words, as Hayes argues in his book, America isn't truly a meritocracy. Sure, the Civil Rights movement, feminism, and equal opportunity laws have helped to remove many of the barriers to success..._

A _merit_ ocracy, by definition, is some sort of social hierarchy based on merit -- you take a test, you gather in the most bottle-caps, you beat your classmates at arm-wrestling. Whatever. Things like the Civil Rights Movement deal with correcting historical and societal injustices. Instead of something you _do_ , you are being judged, at least partially, by something you _are_. This is done for the betterment of society.

Don't want to argue social engineering, but viewing somebody by what they are is 180-degrees away from viewing them by how they perform in some kind of merit-based system. For the author to juxtapose these two concepts in his mind as one being an example of the other is just.......sad. Perhaps his premise was more about the matter of how he felt various social ideas that are supposed to create a equatable social result such that more minorities or women succeed but instead create additional stress. That's fine, but that's not a meritocracy.

The article goes downhill from there.

<comment><USER10> This article is quite well-researched and argues that the meritocracy that you imagine doesn't exist in practice. As such you don't respond to the article at all, but for some reason feel compelled to use snarky tropes (whatever, sad, downhill) even when you admit the you have nothing to say. Why?

<comment><USER9> I believe I made my point that the author either doesn't understand or is purposefully misusing the term "meritocracy". Not really sure why you think I have nothing to say. Was my point not clear enough?

The reader is invited to make further critiques.

If you don't understand parts of your premise, no matter how well-reasoned and well-researched your article, it's going to tank.

By the way, this is an editorial problem, not a problem with the author, or perhaps even the thrust of the piece. I think in terms of content the author did a great job. It just needed another set of critical eyeballs to shine it up. It's a damn shame if you ask me: obviously a lot of work went into this. HN isn't the most author-friendly place in the world. If somehow my critique appeared facile, you have my apologies. I'm not going to further argue with you. I'm sorry if somehow a few colloquialisms threw you off the trail of my point.

Having said that, I still am getting tired of The Atlantic Article Of The Day appearing at the top of the page. They do some great long-form work every now and then, but in my opinion the amount of coverage it gets here is quite disproportionate to the value it provides the community.</comment></comment></comment>


Show HN: Open Source emulator in Javascript that runs Linux - <AUTHOR> http://www.ubercomp.com/jslm32/src/

<comment><AUTHOR> Since there seems to be some interest on the subject, and I don't want to kidnap the great thread about the worst Linux PC ever [1], I decided to submit on a separate thread.

Some things do keep in mind:

1\. Very early stage. Runs better on Chrome.

2\. If you think this sucks, you're probably comparing my code to Fabrice Bellard's Jslinux[2], and as Bellard is a genius his code (which is unfortunately still not available in readable form) is probably much better than mine. But progress is being made.

3\. Still, the potential is there, soon it will be possible to have a somewhat standard programming stack and write GUI applications that run off a canvas, as I said in [3].

4\. For Chrome there is a nice terminal emulator (hterm) I lifted from the Chromium source tree. The rest use _textarea_.

5\. The code, of course: <https://github.com/ubercomp/jslm32/>

If anyone has questions, I'll be happy to answer them.

[1] <http://news.ycombinator.com/item?id=3767410> [2] <http://bellard.org/jslinux> [3] <http://news.ycombinator.com/item?id=3769486>

EDIT: Added itens 4 and 5.

</comment><comment><USER2> Very nice. Is there any chance of a follow up on your comment in the previous thread:

"I'll write a post describing what I did to take boot time from 2.5 minutes to 10 seconds."

My interests:

\- how did you find what to optimise? \- what approach did you use?

<comment><AUTHOR> > \- how did you find what to optimise? - what approach did you use?

I used profilers: Chrome developer tools and Firebug. The Chrome profiler is very nice and easy to use, but it looks like it is a statistical profiler. When the usual invocation takes less than 1ms, it might get the times wrong (there might be a bottleneck that Chrome profiler is not showing).

The Firebug profiler is more precise, I believe it traces every executing instruction, which also makes it much slower to run you program in, but does sometime gives you interesting insights.

Also, there's intuition. I wanted to keep the code readable. The interpreter loop is basically something to the effect of

      while(true) {
        op = decode(mmu.read_32(cs.pc));
        cs.pc += 4;
        (optable[opcode])(op);
      }

which I believe is very readable, but it counters everything one expects about writing fast javascript code that runs in a tight loop. Bellard told me he thinks my "dynamic interpreted" version might be slower than a throughly optimized interpreter version, and he might very well be true. But I found the readability of the interpreter to be of the upmost importance, at least until I had a working "dynamic recompilation" version.

To optimize the interpreter version, the profiler showed me that basically three things take most (about 65, 70% of the time: * Instruction decoding * Memory access

There's not much I found to make instruction decoding faster , but the memory access time could be improved. In the beginning, I used the form mmu.read_32(addr) to read from any region of the memory, including RAM. Most of the accesses are of course from RAM, so it made sense to optimize for this fact (despite it being bad for readability).

So nowadays I do: op = (v8[rpc] << 24) | (v8[rpc + 1] << 16) | (v8[rpc + 2] << 8) | (v8[rpc + 3]);

For memory accesses.

Some other things I found randomly. The processor in the board I'm emulating has a 75Mhz clock. With that emulated frequency, Linux was spending a lot of time on the "idle task". Whan I told the emulator that the frequency was about 8Mhz, the problem went away.

Then, I thought to myself: it would be neat if I could implement parts of the libc in Javascript. That's how [https://github.com/ubercomp/jslm32/blob/master/src/lm32_libc...](https://github.com/ubercomp/jslm32/blob/master/src/lm32_libc_dev.js) came to be. So I implemented some string.h functions in javascript (memcpy, memmove, and memset), and voilá, the boot time went down about 3 times.

But in the end of the day, lm32_libc_dev is a hack with very negative consequences. I would have to modify every program I wanted to run on the emulated board to use my libc functions instead. I did this with the linux kernel and it was a bad experience. So I focused my energy on the dynamic code generation side of things.

I can tell you I have succeeded as the jslibc thing is now deleted on my local source three and I didn't experience any slowdowns whatsoever.

<comment><USER2> Thanks for this, it's a great piece of work and very easy to read. Nice code.

> "it looks like it is a statistical profiler. When the usual invocation takes > less than 1ms, it might get the times wrong"

I don't understand this. As long as the statistical profiler can interrupt at any point, surely a routine running for 10k times for 0.1ms will still be interrupted a similar number of times as one routine running for 1s? Or are you thinking that there may be a bias to the sampling? (e.g. method of interrupting means we're not likely to see the first N ops after a method call or something)?

Did you see a significant difference in the profile between the two profiler approaches (firebug/chrome)?

> For memory accesses.

I wonder if your RAM accesses are mostly 32bit aligned and made in 4bytes at a time? (I guess you could instrument to find out)? If so, you might get a further speedup by having the RAM array stored as 32bit quantities instead of bytes, doing:

op = v832bit[rpc]; // only works for aligned code

and then having the RAM read/write 8/16 be special cases on top of that? That could also give a speedup on memmove etc (4x speedup?), making the libc hack less necessary?

<comment><AUTHOR> > I don't understand this..

Well, I won't speculate on the workings of the Chrome profiler, but what I can say is that profiling in Chrome and Firefox gives different results (which may of course be caused by differences in the Javascript engines).

> I wonder if your RAM accesses are mostly 32bit

All accesses on the LM32 processor are aligned. Half word accesses have 2 byte alignment, and word accesses have 4 byte alignment. So in theory it would be easy.

I use ArrayBuffers for the RAM array (where supported). You can have different views for the same array buffer, so in theory I could have the ram ArrayBuffer with an 8bit view, a 16bit view, and a 32bit view, where each would be used for accesses of their size. In that sense, you're absolutely right and I think a good speedup would be achieved by that change (something like 2x speedup as most accesses are in fact 32 bit).

I don't do that for endianness reasons. The LM32 is big endian, and most devices nowadays are little endian. Unfortunately, the state of ArrayBuffer is still kind of chaotic, in that the endianness of the ArrayBuffer is the endianness of the host (they do this for performance reasons). So I can't do the v32[rpc] thing. Theoretically, I could if the programs have Read-Write consistency, i.e., if they only used the same size for reading and writing some data, which they don't. A program that tests the endianness of the processor, for instance, does not have read write consistency.

I could use ArrayBufferViews to access memory in an endianness-independent way, but I tried it and it's actually much slower.

To make memory faster, two things can be done either: 1) emulate a little endian processor instead. 2) have a fast byteswap operator in javascript, without a function call (never gonna happen).

So since 2 is never going to happen, the solution is to tackle 1.

<comment><USER2> Ugly thought - if "almost all" accesses are Read-Write consistent, maybe an exception list of addresses could be used?

Basically do the 4byte cell approach, and make most of your RAM the "fast" endianness, with some 4byte cells "correct" endianness, because you know they are being accessed in a way that cares. (Since you're interpreting, I'm guessing this is reasonably-easily detectable?)

It does put a "if-addr-on-exception-list" on your mem access path, but if that's a hash lookup it could be OK. If you can further guarantee that your text segments are always fast-endian, then your opcode dispatch loop can still go direct and miss out that test.

<comment><AUTHOR> That would actually work, I guess :). I'm pretty sure the memcpy, memmove, etc. implementations I've seen for this architecture all work by copying one byte at a time (argh!) though, but that problem can be solved with some smart- if-ugly hackery.

But, as you said yourself, it would be kind of messy, in that it would be hard to be certain if it works in 100% of the cases.

I think it would be easier to just change the toolchain code and make it think the processor is little endian.

</comment></comment></comment></comment></comment></comment><comment><USER3> Hey reginaldo, for some reason I cannot enter any text on the terminal, hence, I cannot login. I'm using Chrome 18 on OS X Lion. Just in case, I tried downloading the code and running it locally: same result. Any ideas?

<comment><AUTHOR> Yeah, it is a known bug. The hterm terminal emulator runs on its own iframe, so you'll have to click anywhere on the screen (outside the terminal). If that doesn't work, then it's a new bug...

</comment></comment><comment><USER4> You mentioned in the 'Worst Linux PC' thread that your implementation generates JS code on the fly and 'captures up to three backwards jumps'. Do you mind explaining in more detail how this works?

<comment><AUTHOR> Ok, one way to do interpretation is to do a loop like

      while True:
        instr = decode_instruction(pc)
        execute_instruction(instr)

Where execute instruction is usually a big switch that has every opcode on it, or, in my case, is a call to a function in a table whose indices are opcodes.

The problem is you decode the same instructions many times (in a loop, for instance). A slight more elaborated version is like this:

      while True:
        if not pc in cached_code:
          block = generate_block(pc)
          cached_code[pc] = block
        run_from_cache(pc)

The generate_block function decodes and generates code for every instruction until it finds a jump. When it finds it, it finishes up that block, which is then added to the cache.

Now, whenever there is a jump to an address that is in the cache, the cached code can be executed directly.

Finally, the captures up to three backwards jumps thing:

My first try was to have the cached code just be a regular function call without loops. So a block of code is executed and then control is given back to the main loop.

But a significant number of jumps have targets that are inside the same block of code (anything you run on a loop, for instance). So, to get better performance, I generate, for my block of code, a function that has a loop in it.

It has a rather characteristic look:

      function code_block(cs) { // cs is the "cpu state"
          var count = 0;
          cs.next_pc = BLOCK_START;
          block_loop: while(++count < 3) {
              count++;
              block_choice: switch(cs.next_pc) {
                  case BLOCK_START: cs.r0 = cs.r0 ^cs.r0;
                  case BLOCK_START+4: // regular instructions fall through
                  case CONDITIONAL_BRANCH_ADDR:
                      if(branch_condition) {
                          cs.next_pc = BRANCH_TARGET;
                          break block_choice; // this captures backwards jumps targeting the block
                      }
                  case  UNCONDITIONAL_BRANCH_ADDR:
                          cs.next_pc = BRANCH_TARGET;
                  default: break block_loop;

              }
          }
      }

The "captures up to three backwards jumps things" is controlled by the ++count < 3 loop condition. 3 was obtained by trial and error and looks like a good number for my machine (I could, for instance, put 100 in there, but then my javascript functions would take too much time to return and the javascript engines don't like this).

<comment><USER4> Thanks for the explanation! It makes sense. I was just wondering though -- why is it necessary for generate_block / decode_instruction to be called on the fly, instead of as a pre-compilation step? I guess you need some sort of runtime information for the compilation?

<comment><AUTHOR> What you're looking for is called static recompilation. It's what Emscripten [1] does, it statically recompiles LLVM bitcode to javascript. Emscripten is a wonderful project, by the way. After compiling from LLVM to Javascript, it applies an algorithm (relooper) to the "intermediate" javascript code whose result is code that resembles the structure of the original code so that, for instance, if the original code has a loop, the final javascript code will also have a loop. It is a true gem, and it's part of what makes Emscripten so awesome and fast.

I believe I could do static recompilation for programs that run on a barebones environment and do not employ self modifying code. The more general problem of finding all executable code in a blob of arbitrary binary data (which I would have to solve if I wanted to run an arbitrary program unmodified, which I do), is equivalent to the Halting Problem, so that is a no go. This means that, to have a general solution, a hybrid approach of static and dynamic recompilation would have to be employed.

For well behaved programs, code generation on the fly does not pose a significant overhead (that's what the profiler tells, if I recall correctly), so I'm not sure the hybrid approach is worth its weight in complexity.

Besides, I don't know if I'd be able to run a full OS, though, because those need interrupts (in my case, currently there's a timer tick and the UART interrupt when input is entered through the keyboard), and I haven't thought about handling that.

[1] <https://github.com/kripken/emscripten>

<comment><USER4> Yup, I'm aware of Emscripten, which was part of the reason behind my question. I hadn't considered the issue of lack of code / data separation when dealing with pure binary code.

I'm actually working on a JVM interpreter in Coffeescript now, so this topic is particularly interesting to me. Thanks again for taking the time to explain things.

</comment></comment></comment></comment></comment><comment><USER5> Is the idea of an "average" customer really this lost on so many tech writers? I thought my little sister was tech-literate, but she doesn't give a shit about "Ice Cream Sandwich"... she has customized the hell out of her 2.3 handset and there's nothing that she wants changed. How many "average" customers are entirely satisfied with the smallest amount of customization the system allows?

I'm returning my new iPad this week because 1) My Macbook Air is light and more useful, I have no drawing ability, and I don't read much; the iPad is no more than a toy and waste of money in my ecosystem, and 2) The app store ecosystem is dreadfully boring on iOS. On Android I feel like I'm actually rewarding the good developers by buying their Pro versions of apps and such... on iOS everyone wants your money, regardless of how shitty the product is. On Android, I see so many developers experimenting across so many categories just for the fun of it. 3) High-resolution has hardly benefitted anything that I do on the device. The majority of content that I see (images and video) are low- res. Plus, very few apps that I use have been upgraded to 'retina' quality. ALSO, retina doesn't just mean scaling everything up... why is nobody making their content more detailed? Orthogonal lines don't render that differently in higher resolution.</comment>


Episode 3: Interview with James Gosling, Father of Java - <AUTHOR> https://www.mappingthejourney.com/single-post/2017/06/29/Episode-3-Interview-with-James-Gosling-Father-of-Java? <comment><USER2> Definitely keen on listening to this podcast, especially after hearing so many people in the (Amazon) office keep shouting over the cubicles, "Did you hear we hired James Gosling?!"</comment>


Power vs. Speed: The Xbox Series X And PS5 are different animals - <AUTHOR> https://www.forbes.com/sites/kevinmurnane/2020/03/22/power-vs-speed-the-xbox-series-x-and-ps5-are-very-different-animals/#6eea45bf29d7 <comment><USER2> Polaris and Vega were ROP-limited, and performed worse than nvidia cards with similar tflop measurements.

The Xbox has a higher tflops rating because of more compute units, but it has the same number of raster units. Because the PS5 clocks higher, its ROP throughput will be greater. In a rendering workload like games this will make a difference. Whether or not this offsets the fewer compute units remains to be seen, but I'd wager the consoles are going to come out pretty much on par. There's not going to be a big discrepancy like PS4 and Xbone.

<comment><USER3> You're missing one of the key pieces: software. I don't think many would argue that Sony can produce better tooling and operating system efficiency than Microsoft.

Even with identical hardware, I'd place my money on a small Xbox edge.

The PS3 was on paper significantly more powerful than the Xbox 360, however it didn't result in significantly better performance or graphics. In some games in some cases yes, in others not really.

<comment><USER4> Doesn't Sony use clang? My understanding was LLVM does a better job at optimisation than MSVC.

</comment></comment></comment><comment><USER5> I'm failing to see how power and speed differ in a computing context.

CPU wise PS4 is weaker and slower, no matter how you frame it. Maybe on the GPU side you could make an argument for that difference, but still.

Either way, seems like a strong move forward for gaming.

<comment><USER6> There's a couple of things in the article. The Xbox has a faster CPU, but the PS5 has a faster SSD. The Xbox has more GPU cores, but the GPU cores of the PS5 are faster. I would say number of cores versus speed equals how power and speed differ.

</comment></comment><comment><USER7> I haven't bought a console since the Wii. With xbox vs Playstation battles, do people often switch consoles, have both or stick to their favorite? It almost seems similar to iOS vs Android in some ways.

<comment><USER6> I hear PS4 outsold Xbox One by a mile but it's strange because I only know people who either have the Xbox One or both. I don't know anyone who has just a PS4.

I know it's a small sample size, and not representative it's just a interesting.

I personally have both, and I prefer the Xbox One. We actually have two so I can game with my wife. The UI feels less like a toy, setting up groups and games is still much easier with Xbox Live than anything PlayStation has ever offered.

<comment><USER8> maybe it's a regional thing? everyone I know has a ps4 and I only know one or two people with an xbox

</comment></comment></comment><comment><USER9> Has anyone figured out if these new consoles will run games at 120/144Hz refresh rates?

I'm thinking of going back to console after years of PC (mostly due to space constraints and not having time to mess with fancy builds again) but 60 Hz is the single biggest deal breaker for me. Switching to a lower refresh rate even for a few minutes now gives me a headache

<comment><USER10> Not sure if they support running games at those refresh rates, but either way there won't be many if any AAA games that would actually be running +60 FPS. If we can even get stable 60 FPS for most titles with 1440p or 4K, I'll be surprised.

In the end it's still the graphics what sells and not the FPS for most people and definitely for most people buying game consoles. In the current gen, lot of games are still running 1080p@30FPS: [https://www.ign.com/wikis/xbox- one/PS4_vs._Xbox_One_Native_R...](https://www.ign.com/wikis/xbox- one/PS4_vs._Xbox_One_Native_Resolutions_and_Framerates#PS4_vs._Xbox_One_Native_Resolutions_and_Framerates_Comparison_Chart)

</comment></comment><comment><USER11> Clickbait article, they are very similar. On PC the CPU was hardly ever the bottleneck so I expect not much from the options MS is offering there.

<comment><USER12> We have GPUs becuse of the CPU bottleneck, it's been a very big thing.

<comment><USER13> That's just nitpicking. Just because something is turing complete doesn't mean it is optimized for a specific task. The responsibility of processing graphics has been shifted away from the CPU for a long time already.

<comment><USER12> I think you are working with an oversimplified model of graphics programming if you think graphics code runs just on the GPU.

But even in this ideal scenario, there would already big sacrifices involved in just offloading this stuff to GPUs: Sacrifices in SW complexity and development time moving from programmer-friendly CPU code to hard-to-program GPU interfaces.

The reality is in fact a CPU+GPU juggling setup where interacting CPU and GPU computations must be carefully coordinated and performance-tuned.

If the CPU bottleneck didn't exist and we could do without today's GPUs, we could make better graphics applications (games) given the same investment and technical engineering competence, and game developer life would be much more pleasant.

(There's an alternate history of more programmer friendly GPUs of course too, see eg the Larrabee story)</comment></comment></comment></comment>


Nuclear Magnetic Resonance and Fourier Transform (2017) - <AUTHOR> https://compphys.go.ro/nuclear-magnetic-resonance-and-fourier-transform/ <comment><USER2> This is a nice overview, however, the images seem to be for NMR imaging (NMRI) while the equations are for 1D NMR. As other posts comment the NMR only portion can be relatively simple, but it's usually used to characterize chemical samples by their resonances. Imaging is very different.

I'd note that for 3D NMRI the challenge of tomography (extracting the 3D data from a bunch of interfering resonant torus regions) is actually more difficult in practice (I haven't heard of ML/DL techniques, but I'd expect they are now used) though the concept of NMR (without imaging) is more physically interesting. Furthermore, when chemistry is important the fitting algorithms to extract weak NMR signals overlapping strong signals is actually also moderately complex and over looked here for the sake of clarity and brevity.

<comment><AUTHOR> The Fourier Transform in 2D or 3D is not really a much bigger deal, that's why I handled only the 1D one there in equations (I was too lazy to type in latex, I guess). NMR spectroscopy is indeed quite different than NMR imaging, I might have something about that on the blog sometime, it would be an interesting topic...

<comment><USER3> I find how the Fourier Transform works so simply in multiple dimensions as long as you have cartesian sampling is where the transform starts to shine. Just apply along one dimension then the others and because it's a linear unitary operator they are incredibly robust and it makes no difference which order you apply them. Then you can combine them with other measurement types in higher dimensional measurements (e.g. a relaxation period) and still just mindlessly apply the Fourier Transform along the frequency dimensions (first since it's so robust) and get the desired result.

There isn't any difference in the Fourier analysis between spectroscopy and imaging. In imaging you're just encoding position as a frequency and if you enforce Cartesian sampling the analysis remains the same, including combining extra dimensions. Spectroscopy and flow imaging experiments can get pretty crazy with 5-6 encoding dimensions limited only by your patience and instrument drift over longer periods (weeks).

The differences between spectroscopy and MRI are primarily application driven and then because it is tricker to apply precise magnetic field gradient pulses vs precisely timing RF pulses. Combined with the fact people are a lot bigger, more impatient and more delicate than test tubes while imaging can also be far less quantitative drives the design of very different NMR/MRI pulse sequences. In imaging, the speed gains and human placed limits on gradient slew rates (Audio frequency dB/dt induces currents in neurons) often justify the trouble of non-Cartesian and/or incomplete sampling.

If you want a next step for MRI signal processing, look into multiple-coil reconstruction techniques and how they not only combine the spacial sensitivity profiles of the coils with gradient imaging, without knowing the actual sensitivity profiles a-priori. Pretty much every medical MRI machine uses multiple receive coils to reduce imaging times.

Note: My user name is proton gamma though I left the field mid-career to do sw development. (A far better career though not as exciting if you love physics like I do.)

(edits: grammar, probably still missed a few typos)

<comment><AUTHOR> Of course there isn't any difference in the Fourier analysis, but there is a difference between spectroscopy and MRI, enough to warrant a different post on the blog. In the MRI case you have a human with macroscopic inhomogeneities, while in the spectroscopic case you are not interested in those macroscopic inhomogeneities, but in the local differences in molecules, that the active nuclei 'feel'. It's quite a difference in scale and also you have one human in the 'sample' in the case of MRI, but many molecules in case of spectroscopy :)

</comment></comment></comment></comment><comment><USER4> The software we had to run in O-Chem lab would take the raw files from the NMR machine, run the FFT on it, then integrate the results. I was able to "borrow" a copy of the software myself so I could run the analysis on my NMR specs outside of lab.

<comment><USER5> Could have just taken the FID data and computed it in Julia in five lines of code!! (but you might not get that fancy tool that makes your integration shoulders nice and even.) Still though bruker charges an arm and a leg for the postprocessing of 1ds

<comment><USER6> Topspin is free for academic users for a while now, so that has changed at some point.

And while it's certainly possible to process 1D NMR spectra with a bit of code, it's certainly more than 5 lines. There's stuff like removing the digital filter that is an implementation detail of Bruker spectrometers you have to deal with. The FFT is the smallest parts, you also need window functions and phasing to make something useful. And for 2D NMR you additionally need to handle the various methods of quadrature detection in the indirect dimension.

</comment></comment></comment><comment><USER7> This is one of the most accessible explanations of the mechanics of magnetic resonance imaging that I've come across. Thanks for sharing.</comment>


Worse is better - <AUTHOR> http://en.wikipedia.org/wiki/Worse_is_better

<comment><USER2> I agree that less is often more. It's better to do a few things well than to do many things poorly, the latter being an inevitable result of feature creep and design by committee.

That said, I tend to hold to the MIT Approach: correctness and consistency should not be compromised.

<comment><AUTHOR> It sort of feels like an extension or parallel to "Perfect is the enemy of good."

</comment></comment><comment><USER3> Clay Shirky's recent post on complex business models reminds me of this. [http://www.shirky.com/weblog/2010/04/the-collapse-of- complex...](http://www.shirky.com/weblog/2010/04/the-collapse-of-complex- business-models/)</comment>


Ask HN: What mailing lists do you subscribe to? - <AUTHOR>

<comment><USER2> Fewer than I thought:

\- [http://www.edge.org](http://www.edge.org) for long emails about interesting topics.

\- A few Stack Exchange weekly newsletters (stackoverflow, programmers, workplace, superuser, stats, data science). The signal to noise ratio can be pretty low but they're easy to skim through.

\- Local tech / machine learning groups.

\- This week in swing NYC ([http://thisweekinswingnyc.wordpress.com/](http://thisweekinswingnyc.wordpress.com/)).

I used to get a lot more through rss until Google killed its reader. After halfheartedly looking for alternatives, I decided it wasn't worth it and simply gave up.

</comment><comment><USER3> [https://www.schneier.com/crypto-gram- sub.html](https://www.schneier.com/crypto-gram-sub.html)

[http://www.homelandsecuritynewswire.com/topics/cybersecurity](http://www.homelandsecuritynewswire.com/topics/cybersecurity)

[http://www.sans.org/newsletters/](http://www.sans.org/newsletters/)

</comment><comment><USER4> The Ryan Holiday Reading Recommendation Email (lots of biography/non-fiction books) [http://www.ryanholiday.net/reading- newsletter/](http://www.ryanholiday.net/reading-newsletter/)

Golang Weekly Newsletter [http://www.golangweekly.com/](http://www.golangweekly.com/)

</comment><comment><USER5> Really just some listservs for school organizations/information.

When I was actively doing virology research, I subscribed to ProMed to keep up to date with disease outbreaks, but that was pretty niche specific.

I usually don't like my inbox being hit by mailing lists, too much noise.

</comment><comment><USER6> \- stackoverflow

\- my kids' school's listserv

\- Alexis Madrigal 5 things

everything else is RSS

</comment><comment><USER7> lurking on my local linux users group. shroud of the avatar updates. everything else is rss.</comment>


The Gig Economy - <AUTHOR> https://zerohplovecraft.wordpress.com/2018/05/11/the-gig-economy-2/ <comment><USER2> This was a great read, thank you for sharing it! If you haven't read the Daemon books by Daniel Saurez, they are in the same vein.</comment>


Show HN: I made a chrome extension to bypass paywalls through archived versions - <AUTHOR> https://github.com/ImedAdel/arkiv <comment><USER2> I'm hoping for one that automatically redirects to mobile versions. Since I do most things on Raspberry Pi, for example, I read mobile.cnn.com instead of the www version of articles. Same with twitter. But as of yet I haven't seen anything that rewrites clicked url's that way.

That mixed with your plugin would be divine since some of the paywall popups lock the rpi up for a bit in the same way excessive graphics, never ending content background loads, animated ads, etc, do.

</comment><comment><AUTHOR> PS: I still haven't really figured out how to make the .crx file installable on chrome...

<comment><USER3> You gotta pay $5 developer signup fee and register in the chrome store. Or I think you can drag the file into the extensions tab for local installation.

[https://developer.chrome.com/webstore/publish](https://developer.chrome.com/webstore/publish)</comment></comment>


Plaid Launches in the UK - <AUTHOR> https://blog.plaid.com/plaid-in-the-uk/ <comment><USER2> Open Banking is a big buzzword at the moment. It is good to distinguish different aspects of it:

1) Regulation. What you heard as "PSD2" \- is essentially a directive by European Commission and EBA demanding banks to open up access to accounts data and payment initiation. Neither it defines by what means this access should be provided, nor when it should be available - each European country Central Bank can decide on its own.

2) Technical Specification. Examples are OpenBanking UK specification or The Berlin Group - would be groups of banks or local regulators trying to define common standards. Think of interface definition that describes both APIs as well as journeys/workflows.

3) Compliance. In the EU some of the banks (mostly large ones) are now required to be PSD2 compliant, which means they would need to expose their APIs through the standards described above. In the US, where there is no such requirement - the only way to access the bank account is to emulate a browser.

4) Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) - would essentially provide access to the accounts of multiple banks via APIs. If you look at Plaid in the US - their codebase is probably 50%+ screenscraping/user emulation scripts in order to retrieve your accounts from e.g. Bank of America. For the EU fin-techs its a bit better, but still depends per country (remember Berlin Group vs UK OpenBanking?).

<comment><USER3> > would be groups of banks or local regulators trying to define common > standards

Why 'would be' just out of interest?

AFAICT Open Banking is an organisation that has been given a mandate by the UK government, through the competition and marketing authority, and is funded by the nine largest retail banks. In the UK it _is_ the defacto standard, and compliance of the CMA 9 is mandatory.

While there is so far no consistent standard across the EU, at least within the UK this one is set and pretty much non-negotiable.

(Disclaimer - I have consulted with Open Banking and continue to do so, but of course I do not speak on their behalf)

\-- edit --

I'm particularly interested in this -

> Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) > - would essentially provide access to the accounts of multiple banks via > APIs.

As AFAICT this would be explicitly disallowed unless all the users of said APIs are themselves accredited. You can't just get accredited for PSD2/OB API use, then expose that information to non-accredited entities. If this is what Plaid are doing then I wouldn't expect their accreditation to last all that long.

<comment><USER2> > Why 'would be' just out of interest?

The scenario is typically the following. After the EU Commission approves the directive, each country has to transform it into the national law and define the authority/approach/timelines. In the case of the UK, it's indeed the way you've described.

> As AFAICT this would be explicitly disallowed unless all the users of said > APIs are themselves accredited.

In UK Plaid would have to follow the OpenBanking regulation indeed and provide access according to the consent of the account owner. In the US they are just storing your password and using it according to their privacy policy.

<comment><USER3> I'm not sure they would be allowed to provide access to another party _at all_ , if the other party wasn't accredited, regardless of consent.

I'm sure they've looked into this with their lawyers, but acting as an escape route for banking data to non-approved entities is not likely to be smiled upon.

<comment><USER4> They are allowed to provide access but with a few stipulations:

Firstly, the consumer _must_ be aware that they are sharing their data via Plaid (i.e. Plaid can't hide behind the scenes).

Secondly, there are certain exceptions for needing to be regulated by the FCA - particularly if you don't show any data back to the user.

In practice, it makes sense to be regulated by the FCA regardless because asking to share bank information/transactions with Plaid can turn users off and you're limited with what you can do with that data without being regulated/authorised.

Source: Fintech founder in the UK/Ireland.

<comment><USER3> I find that surprising, given the lengths OB go to to ensure that only registered, accredited entities can participate in using their APIs. I'm not saying you're wrong, just that I find it surprising.

(Source, I consult with OB and have a hand in their PKI, I don't speak for them and I'm not part of or informed well about anything to do with the regulatory environment)

</comment></comment></comment></comment></comment></comment><comment><USER5> Use at own risk* [1]

[1] [https://github.com/plaid/link/issues/68](https://github.com/plaid/link/issues/68)

<comment><USER6> There's legitimately no alternative, "secure" way to access someone's banking data other than by asking for a username/password and then 'impersonating' them / asking for 2FA codes etc etc. As a commenter on the issue says, there is no oauth-esque mechanism implemented by banks.

I think plaid is the lesser evil when compared to rolling all of that on your own for N different banking institutions.

<comment><USER7> Have you read about [https://www.openbanking.org.uk/](https://www.openbanking.org.uk/)

The nine largest banks and building societies are required to participate. Many others do so voluntarily.

<comment><USER8> What percentage of the world's banks are covered? Or perhaps what percentage of the world's population banks in those covered institutions? Or perhaps what percentage of the total banked wealth (terminology?) is held in covered institutions?

<comment><USER7> On an article titled "Plaid Launches in the UK" I would assume the most relevant territory is "the UK".

But if instead the question is "what's the alternative" the answer is "government intervention" as shown by the UK.

<comment><USER8> It depends on the audience. Many businesses don't want to restrict themselves exclusively to the subset of UK banks that follow that initiative. And government intervention is hardly a pragmatic solution (how many companies can afford to lobby every government in which they'd like to do business?).

</comment></comment></comment></comment></comment></comment><comment><USER9> I don't have anything to say about the product/launch but that homepage is one of the better designs for a marketing website I've design in a while.

The typography on the docs page is excellent: [https://plaid.com/docs/quickstart/](https://plaid.com/docs/quickstart/)

<comment><USER10> It looks OK if you have your browser set to the default 16px font size. If not, that page might not look good at all, because unfortunately it uses a fixed line-height but keeps the browser-configured font-size.

</comment></comment><comment><USER11> In the UK, 'Plaid', capitalised and in writing, usually refers to [https://en.wikipedia.org/wiki/Plaid_Cymru](https://en.wikipedia.org/wiki/Plaid_Cymru) . It's not pronounced the same as 'plaid' though.

<comment><USER7> Yes this link was not what I initially expected. My first thought was that Plaid Cymru was expanding to the whole of the UK, not just Wales.

<comment><USER12> Interesting to understand what you imagined the objectives of such an expansion would be?

<comment><USER13> The Irish Nationalist Party once got an MP elected in Liverpool:

[https://en.m.wikipedia.org/wiki/T._P._O%27Connor](https://en.m.wikipedia.org/wiki/T._P._O%27Connor)

In that case, the objective was to argue for home rule for Ireland. And to look out for the large Irish community in Liverpool.

</comment></comment></comment></comment><comment><USER14> Doesn't Open Banking ([https://www.openbanking.org.uk](https://www.openbanking.org.uk)) make this sort of middleman unnecessary in the UK?

<comment><USER15> Open Banking means you can access your own banks API, however if you have a lot of customers and you need to access lots of different APIs from different banks then you use an intermediary 3rd party, e.g TrueLayer and you use their API to access the open banking API of the customers bank.

<comment><USER14> I don't think that's entirely correct. Open Banking means that all participating banks allow access via the same API, which is documented here:

[https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16320...](https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16320694/Open+Data+API+Specifications)

The biggest UK banks have a legal obligation to participate and many smaller ones are participating as well.

I can see why a third party API gateway would still be useful internationally though.

</comment></comment></comment><comment><USER16> Plaid is how most people refer to Plaid Cymru, a Welsh nationalist political party, in the UK.

<comment><USER17> And to me as a continental european, Plaid always triggers [https://youtu.be/LU8seZlfhw4](https://youtu.be/LU8seZlfhw4)

;)

</comment></comment><comment><USER18> Would love to hear from HNers in Europe (and elsewhere) which countries Plaid should go to next!

And also what the biggest pain points are to building fintechs in other markets.

<comment><USER3> Presuming you are from Plaid - can you tell me what your position is on what I think I'm seeing - OpenBanking APIs opened up to non-accredited organisations using yourselves as a gateway - and whether that's in keeping with your accreditation?

I.E. The APIs available in the UK are designed to open data up to competition, but only within the limits of those orgs that are FCA accredited for PSD2 Roles of various sorts. Are you allowed to let others piggyback on those?

</comment></comment><comment><USER19> Looks interesting but there doesn't seem to be al list of supported banks?

Pretty happy with Truelayer ([https://truelayer.com](https://truelayer.com)) but more competition is always better.

</comment><comment><USER20> Am I missing something or have Yodlee and Intuit account aggregation have provided this service now for more than a decade?

</comment><comment><USER21> Plaid has registered as an AISP ('Account Information Service Provider'), which means that they can register for and use the Open Banking APIs provided by UK banks.

These APIs use an authorisation flow similar to what you see when you 'Login with Google' or 'Login with Facebook'. At some point in that flow, you are redirected to your bank's web site to allow access, and to select the account(s) for which you are allowing access. At this point, you are on your bank's web site, you can check the URL to make sure you're not being phished.

On the face of it, it seems like any company that's building on top of bank transaction data should just register as an AISP themselves, as the integration with Open Banking APIs doesn't look that complicated. But Plaid is one of a number of third parties that insert themselves in between.

In general these services suggest some combination of (i) easier integration, i.e. less development and maintenance, (ii) additional intelligence on top of the raw data, e.g. categorisation of transactions, (iii) no need for maintenance.

There's one obvious con: the AISP's logo has to be shown in the authorisation flow. So, even if your users know you, they might not be willing to share their information with 'Plaid' or whichever third party AISP you've chosen.

I don't know how real the development/maintenance/integration issues are. I could imagine that registering with 30+ banks and testing your code against all of them might be a hassle. But if their API backends all behave in the same way, then maybe you just need configuration parameters for the endpoint and token(s). If their backends have slightly different behaviour, though, then perhaps you need to branch your code based on the bank.

One thing that's encouraging about Plaid entering this space: their free tier appears to support up to 100 bank accounts for free. This should be enough for anyone who wants to set up their own self-hosted Mint equivalent. And, if all the accounts are in the UK, then you're giving Plaid just read-only access to your accounts, which is much less of an issue than providing your login credentials to them or another party.

In case you're curious to see which other companies have registered as AISPs or PSPs (payment service providers), the full list of third party providers is available here: [https://www.openbanking.org.uk/provider-categories/third- par...](https://www.openbanking.org.uk/provider-categories/third-party- providers/)

</comment><comment><USER22> Anyone know how this compares to Teller ([https://teller.io/](https://teller.io/))?

<comment><USER3> Teller is a system which relies on screen scraping and taking your passwords (AFAICT, though the comment below says they use the mobile APIs, it's much the same regardless).

In the UK this is no longer necessary and FCA accredited organisations (Or qualified organisations from across the EU) can gain access to Bank APIS which allow much easier, programmatic access with much more granular access and far fewer security implications.

IIRC teller have also been subject to blocking and possible lawsuits from various banks for their scraping activities and are not well liked in the industry.

(--edit-- I am rate limited here so cannot respond below, just to say that if OB APIs are not performant, that'll likely be down to the participating banks. I would expect them to improve over time.

I'm not trying to say teller is illegal - I doubt very much that it would have survived this long if it were illegal - simply that the security model is not so great and the banks don't like it and continue to try to block it. 'Stevie' would probably do well to get himself accredited before the banks find a way to keep him out permanently.)

<comment><USER23> Stevie does address some of the legal side in a comment here: [https://news.ycombinator.com/item?id=14606475](https://news.ycombinator.com/item?id=14606475)

>In the UK this is no longer necessary and FCA accredited organisations (Or qualified organisations from across the EU) can gain access to Bank APIs which allow much easier, programmatic access with much more granular access and far fewer security implications.

I don't have a horse in this race, but in my experience the Open Banking APIs are:

* Not performant

* Poor at handling and reporting errors

* Limited in their functionality

</comment></comment></comment><comment><USER24> Is there a list of supported UK banks anywhere?

<comment><USER25> They are leveraging the Open Banking API, which the nine biggest banks are legally required to support.

The Open Banking website lists 34 banks that currently support it.

</comment></comment><comment><USER26> Da iawn! bendigedig!

</comment><comment><USER27> You should launch in Wales: Plaid Cymru!

</comment><comment><USER28> Same name as a nationalism party in Britain - not going to be popular with a lot of people...

<comment><USER12> Plaid Cymru are unlikely to stir negative associations with anyone in Britain. They are no menace to democracy!

<comment><USER28> Nationalism doesn't have a great track record...

<comment><USER12> I think that Welsh independence would probably not be optimal, but I am pretty confident that it wouldn't be malign.</comment></comment></comment></comment>