Scrum is fragile, not Agile - <AUTHOR> http://www.dennisweyland.net/blog/?p=43 <comment><USER4> He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption.

I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the processes that dominate will reflect those priorities.

On average, the first priority of managers and execs is maintaining the power structures that make them a big deal. But true Agile processes are about empowering teams to self-organize around serving users. Ergo, Sturgeon's Law [2] applies here too: 90% of company software process is crap.

I think reason why Scrum in specific won out is that it combined a process framework unthreatening to executives with the multilevel marketing scheme of Scrum certification. Executives got to keep doing what they were doing, the workers got a "didn't stop breathing" certificate, and coaches got paid. Win, win, win!

[1] [http://williampietri.com/writing/2011/agiles-second-chasm- an...](http://williampietri.com/writing/2011/agiles-second-chasm-and-how-we- fell-in/)

[2] [https://en.wikipedia.org/wiki/Sturgeon%27s_law](https://en.wikipedia.org/wiki/Sturgeon%27s_law)

<comment><USER5> Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

<comment><USER6> Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers.

I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.

<comment><USER7> > Scrum is iterated waterfall.

No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iterations.

> munching through backlog items fed to them by product managers.

That's...not actually Scrum, as it implies that either the role of Product Owner is taken by a PM outside of the Scrum Team or that that the Scrum Team is not self-organizing, either of which is a significant (even if common) deviation from Scrum.

> the blinkers of "sprints" encourage growth of tech debt because nobody has > an eye on the future

Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team's various inspection and process adjustment points.

OTOH, if the Scrum Team is properly cross-functional and self-organizing instead of having a non-team-member imposed as Product Owner, then including appropriate restarting as components of completion of relevant backlog items shouldn't be a problem.

<comment><USER4> What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?

<comment><USER7> > What percentage of Scrum teams do you believe are "properly cross-functional > and self-organizing"?

About the same percentage as that of "Agile" software development shops that put people and interactions above processes and tools.

OTOH, at any place that is considering implementing either, there are decision makers who can influence (or in the case of Scrum more than Agile, authoritatively direct) whether or not that's the case, so for them, at least, it's worth distinguishing between problems with Scrum as prescribed and problems which often occur because decision-makers decided to ignore key parts of Scrum-as-prescribed.

<comment><USER4> Most nominally "Agile" shops are in effect doing Scrum, so I'm not sure that answer helps your case. Either way, it sounds like we agree the "good Scrum" shop is at best rare.

Given that, I think it's worth considering that the problem is Scrum. Especially given that Scrum is not just a process, but an organization and an army of "certified" people that sell services.

When something generally doesn't work for its stated purpose but keeps making money, I think it's worth asking what its real purpose is. E.g., things like crystals and psychics. As Eric Hoffer wrote, "Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket."

<comment><USER7> > Most nominally "Agile" shops are in effect doing Scrum

No, most nominally Agile shops are also nominally doing Scrum, but _actually_ doing not-Scrum in a not-Agile context, largely due to sabotage of both core principles of Agile and foundational elements of Scrum by management.

It doesn't matter what name and superficial ritual you put on the process if it's all window dressing over top-down disempowering command-and-control by persons who are neither doing the work nor experts on the work.

Which isn't to say that the Agile and Scrum bodies of work aren't part of the problem: neither really addresses as a key point how the team effectuates ownership of process and how interaction with management works, which means those gaps get filled in (or rendered moot, in the first case) in ways which compromise what those bodies of work do prescribe because.

Lean, which comes from basically the same perspective (while they don't cite exactly the same values as expressed in the Agile Manifesto, being Lean essentially implies being Agile and vice versa) and is a good body of knowledge to draw from alongside Agile, is better in this regard, and so places nominally drawing on Lean seen to be more likely to be doing what they say, because Lean doesn't leave as much of the core vital parts without good guidance.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue)

* Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board.

* Scrum master driving process above scrum. The scrum master's role is to make sure scrum rules are adhered to. But at this company, any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen. More high-level processes are not optimized because the scrum master defines everything.

* Technical debt. I see this time and time again. User Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. At the end of each sprint, everyone rushes to get their stuff done, and hacks are implemented to meet an arbitrary deadline. Many times I want to begin my work by refactoring something to what it needs to be first, then do the actual user story. But its risky because the refactoring might take more than the allocated story points, and you get dinged. So I do the story first, and if there is time do the refactoring but it almost never happens.

* Poor product owners. During maintenance phase, we could work on cleaning up technical debt, but this value is not appreciated by business so they keep us busy with bikeshedding. One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business.

These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban.

<comment><USER9> The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value."

The project mgmt response was, "Attendance at standups is mandatory."

Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together.

Then I got fired. That solved all my scrum problems.

<comment><USER10> I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.

<comment><USER11> If you do this often enough. People will assume you are busy if you don't show up at all.

<comment><USER12> Don't forget to always roll up your sleeves and carry around some papers.

<comment><USER13> If you are in a paperless office, tapping a tablet with a stylus as you walk confers the same office space prestige.

</comment></comment></comment></comment></comment></comment><comment><USER14> The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role).

Essentially the "process" was:

\- Someone gets an idea to do something, e.g. PMs wants to add a feature.

\- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).

\- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?

\- Manager, PM and other teams get together to figure out priorities, schedules and who's likely to be working on it.

\- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.

From here the devs know what they're trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they're collaborating with and they just figure out amongst themselves how to get things done. They'll keep their managers and the PM updated on progress and any blockers.

Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.

Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It's not hard to gauge develop's productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.

So for me, if you have good competent people that communicate well, you don't really need much process.

<comment><USER15> But how did you ensure that you udnerstood the requirements if you were potentially just left to it for a few months?

At the end was there ever an instance of the client not using what you produced because it wasnt what they wanted?

<comment><USER14> You have direct access to the PM and work closely with them. If you weren't clear on something you ask, if you don't agree with something you debate it out.

Like anything else there is no silver bullet. Sometimes you got the feature right, other times it misses the mark.

</comment></comment></comment><comment><USER16> In my very surface-level, western understanding of Chinese philosophy, Agile seems very much like Taoism and Scrum is like Confucianism, in several ways.

The Agile Manifesto describes a set of ideals but gives no true set of instructions to follow, to do so would not be the Agile way. More than anything, it prescribes an attitude around which you should generally approach things.

Scrum conversely gives rules for how things can be organized and executed in a functional organization. It gives little room for flexibility. Any problems you have with Scrum, the first reaction should be "how are we following the rules wrong?".

Similarly, Tao and Agile are ideals for the individuals (and small teams), Confucianism and Scrum are rules for getting things to work functionally within a society/company.

<comment><USER17> The comparison may be very apt. After all, a key tenet of Taoism is that the Tao that can be told is not the eternal Tao. It may very well be that an Agile development process that can be fully specified and documented is not truly Agile.

<comment><USER18> Somehow I'm reminded of "we demand rigidly defined areas of doubt and uncertainty!" but I'm not sure which side it supports.

</comment></comment></comment><comment><USER19> There's a set of practices here in Seattle that I've come to call Skragile, which evinces the veneer of of Scrum, Kanban, and Agile, but embraces very little of the fundamental philosophies. The most distinctive characteristics:

\- daily standups (often one per day per team so multiple per person)

\- sprint based development cycles, often with retrospectives

\- fondness for the "as an X I want to Y" story

\- story points defined in terms of developer hours or days

\- Kanban style "pick a thing to work on", even in sprints

\- burndown charts

Seems nearly inevitable that when anyone here says "we need more process" they're looking to have more of one or more of the above. I essentially never hear anyone in project management say anything like "we need to build more prototypes" or "we need to streamline our deployment process" or any of the other concepts that would actually characterize a (lower case a) agile development process.

(edited for formatting)

<comment><USER20> This is pretty typical elsewhere too (midwest US as a data point).

Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds).

It feels like we have come full circle to where the new generations of programmers have delegated (or lost) all discipline to managers' Scrum plannings.

Managers and "product owners" aren't engineers or programmers. They shouldn't be expected to "manage" a developer's day-to-day, and yet them presiding over sit-down-stand-up meetings and demanding points and determining deadlines and features is precisely what it has come to. We are right back where we were when the manifesto was drafted.

<comment><USER21> The irony is, when I first saw Agile/Scrum, I thought of it mostly as a tool to provide discipline further _up_ the chain rather than down.

User stories? Oh, a neat way to keep requirements general and open-ended so we can properly address how we're actually going to solve a user's problem. Surely it'll prevent PMs from over-specifying requirements that lose sense of true objectives.

2 week Sprints? Cool, estimates are hard, and now I never have to estimate more than 10 business days worth of labor.

Retrospectives? Great idea, we can finally do proper post-mortems and knowledge-sharing!

Scrum Masters? Wonderful, there's someone whose dedicated to running the process and making sure we have everything we need!

What I wasn't anticipating:

User Stories? But what about critical requirements that need to be prioritized that don't fit into "As an X I need Y"

2 Week Sprints? I now have so much technical debt a repo man is confiscating my laptop.

Retrospectives? This is always going to be 100% about how we didn't estimate correctly and not about far more important matters like: how these features didn't help our users, technical knowledge-sharing, and ticking-out technical debt.

Scrum Masters? Oh, you mean Project Managers?

<comment><USER20> My favorite team experience was scrum done "right". Standups were run by a scrum master who was the most experienced engineer on the team- programming longer than I've been alive type of guy.

Probject managers and product owners were kept at arms length in the sense that they didn't dictate how, what or when we did what we did. They translated the business requirements and timelines into something we could understand and react to.

Somehow, all of that turned into two week sprints that felt sustainable... At least until the company bought out another company, and everything went downhill. That, however, is a story for another time.

</comment></comment></comment></comment><comment><USER22> Managers, not understanding the difference between latency (how long each task takes) and throughput (how much work is getting done in total), always try to optimize for latency. The predictable result: throughput goes to hell, and then latency goes with it.

People who actually write software understand that you have to optimize for throughput first. Not to worry: latency won't be forgotten! But a primary focus on throughput will result in a clean codebase, that will maximize throughput _and_ minimize latency.

<comment><USER23> The rationale is that if you minimize latency, throughput has to be maximum too, so optimizing latency is enough.

In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.

<comment><USER22> > The rationale is that if you minimize latency, throughput has to be maximum > too

Exactly. And it's quite wrong even without taking the growth of complexity into account — as every engineer knows, or should know. Getting every task done as quickly as possible requires a lot of context switching, which is murder on throughput. When you add in the effects of complexity growth (aka technical debt, though I think "complexity growth" is clearer) the disadvantages of optimizing for latency become that much more serious. And the worst part is, as the disease progresses and latency deteriorates, managers try to cure it by applying even larger doses of the poison.

This idea that managers optimize for latency, while I optimize for throughput, occurred to me only recently. But as I look back over the disagreements I've had with managers through the years (including disagreements over the usefulness of Scrum processes!), it's quite remarkable how many of them seem to come down to this.

<comment><USER24> There's pretty good theory behind the idea of minimizing latency to improve throughput. One of the better books on this is "Managing the Design Factory", and a followup called "The principles of product development flow".

These books are not about software development, but of product development in general. The first one actually predates agile, published in 1997.

Core idea is that minimizing the size of the tasks is the best way to improve productivity. Not getting it done as quickly as possible, but to decrease the size.

Remember that product development (new, innovative, uncertainties) vs product manufacting (repeatable), is not a new problem, and not unique to the software industry. There's a lot to learn from product development in other industries.

Another interesting read is "The Toyota Product Development System: Integrating People, Process And Technology" which talks about ways of making product development predictive, and less risky.

It's interesting to see how little software is used to improve the process of software development. Other industries use a lot of software (cad/cam, visual modelling, testing, impact analysis) to improve efficiency and quality of product development. Software for product development is a huge market.

</comment></comment></comment></comment><comment><USER25> I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good.

But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc.

Most places just don't plan for enough time to do things right, and quality is second priority, so no matter what methodology you use, you lose, because no cared about doing it right to begin with.

<comment><USER26> I'm on a team that started doing Scrum a few months ago, and we're still figuring it out.

To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?

<comment><USER25> It did not seem dragged out, it was just thorough, and reasonably un-rushed. It was somewhat tiring, but definitely worth it.

By the end of the planning meeting, we had a clear idea of what we were going to accomplish, and a reasonable amount of confidence that we considered all the tasks that went into our plan.

Because when a story was, e.g. "add addresses to the clients page", it was broken down, discussed, thought out, and agreed upon. The moments when I discovered, oh shit, this story will actually take 10 hours longer than I had allocated, and now I have to stay until 10PM two days this week to meet my committment. Because our story points were approximately an hour each, and almost every story was broken down until there were no tasks more than 3 points each, 1 or 2 preferred.

It was all thanks to our scrum-master/project manager, who had actually spent a lot of time learning about scrum/agile/kanban/etc, read many books on it, and most of all, was committed to doing it right.

I think our sprints were a bit longer than 2 weeks.

</comment></comment></comment><comment><USER27> Whenever I've used scrum, the developers set the estimate and task breakdowns. We even had the developer _doing_ the work provide the estimate. It's not really fair to have someone else estimate your work, it doesn't breed commitment either. We did sanity check things - sometimes an estimate would seem big and everyone else would ask why. The answer was either we had missed something (typically), or (rarely) the estimator misunderstood the task and thought it was something bigger.

At the end of each sprint/cycle we shared estimate vs actual effort, to improve our ability to make a good estimate and set an overall velocity.

On my first Scrum/Agile project, there were complaints of overwork the first sprint. Then I pointed out that we were the ones setting our own estimates, setting the pace and causing our own problems.

After that, the estimates got reasonable. We stopped playing "Name that Tune" with our estimates and the project settled down.

</comment><comment><USER28> I am curious how much process research is being done as an industry. With billions at stake, it seems like I would run across more studies where teams were paid to produce the same software independently. But virtually none of the methodologies I read are backed by much rigorous experimentation.

Maybe it exists and I am just not reading the correct articles.

<comment><USER29> You're 100% right that this is exactly the kind of thing that needs to be tested in various settings to figure out what an optimal setup looks like for different problems. Unfortunately, I had a hell of a time finding actual comparative data with real metrics [1][2]. Pretty sad that 90% of the "research" available is either snake oil or mostly useless comparisons of methodology.

[1] [https://pdfs.semanticscholar.org/85d0/00404206914501d26e0bb4...](https://pdfs.semanticscholar.org/85d0/00404206914501d26e0bb46f079832ef0ce2.pdf)

[2] [https://www.researchgate.net/publication/261047173_Agile_and...](https://www.researchgate.net/publication/261047173_Agile_and_Wellbeing_ --_Stress_Empowerment_and_Performance_in_Scrum_and_Kanban_Teams)

</comment></comment><comment><USER30> There have been a lot of software development methodology but one thing that's been overlooked a lot is the competence of the people doing the execution of the project. I am talking not just about the developers / engineers who are building the product but everyone across the pipeline - product owners, business stakeholders, process specialists, business analysts, project managers and just about everyone else.

People attribute failure to the process because it is demeaning to put the blame on people when _established best practices_ can receive the finger pointing.

Stop the notion of being nice to the lack of skills of people. Hiding behind being nice does not resolve the issue but rather propagates it. Fix the issue by providing the grounds for people to learn and become productive.

<comment><USER31> Yes! One thing I don't see people mention is that Scrum requires that everyone on a team to be competent. It's for teams that are already great that want to be even greater. It's not for teams with inexperience and incompetence. My guess is many people are afraid of scrum because it may out them as incompetent.

<comment><USER32> I'm not saying you're right or wrong, but "many people are afraid of scrum because it may out them as incompetent" sounds like the cliche of "X cannot fail, it can only _be_ failed"

<comment><USER31> Yes, it does sound like a cliche. However, the point of scrum is to find problems that get in the way. Through the process, it's clear who knows what they are doing and who doesn't.

</comment></comment></comment></comment><comment><USER33> The position may be right, but it's so badly argued. Arguments he uses in support:

\- the dictionary definition of "agile" \- how many times the word "agile" appears in the Scrum Guide \- how "lengthy" the Scrum Guide "seems" \- that Scrum is a process, so does not "sound Agile".

Ugh. How did this reach #1 on HN?

<comment><USER34> I think because people are frustrated. My read of the conversation is that there's a lot of latent resentment towards modern Agile and Scrum practices.

</comment></comment><comment><USER35> A long time ago, ppl figured out that no one process was right for every organization, project, technology, etc. They created process frameworks (things used to create a process) and they saw that they were good.

Then ppl came along and said that they were "too complicated" we need something Agile! In actual fact, those ppl didn't understand the process frameworks and just created a specific instance of one and they wondered why it didn't work for all projects, organizations, technologies, etc. And then they said those processes are "too simple" \- what can we do? "Maybe we should create a way of generating a process?", they then said. And so it went...

[https://en.wikipedia.org/wiki/Rational_Unified_Process](https://en.wikipedia.org/wiki/Rational_Unified_Process)

[https://en.wikipedia.org/wiki/Microsoft_Solutions_Framework](https://en.wikipedia.org/wiki/Microsoft_Solutions_Framework)

</comment><comment><USER36> Are we still talking about these dated concepts?

Agile is a mindset.

Understand the mindset, absorb it, make it yours, and build the process that's working for you based on that mindset.

Stop complaining about Scrum, it's just a tool, and tools deprecate.

<comment><USER37> Yep, I've never been in a team where the process was not a regular topic of debate. Once it stops being a topic of debate, it actually just means people are no longer adapting. I prefer a good dose of pragmatism here. Changing the rules all the time is very draining on team morale. Similarly not adapting to obvious process issues is equally demoralizing.

Since everyone is doing, or claims to be doing, agile, the whole notion is completely meaningless. Unless they are actively advertising to be doing some form of waterfall, you can safely assume there is some notion of iterations involved.

What matters more these days is whether the team is mature enough to have continuous deployment without process bureaucracy. Deployment fear is a good sign the process sucks. If you have a need for human gatekeepers, something is wrong with the test automation. Deploying often and with confidence is a good sign you are dealing with a smoothly running team.

</comment></comment><comment><USER38> I don't really have that much industry experience but have been reading a lot about development processes and practices. It seems there just isn't one development process that will solve all your problems and allow you always create successful software. To me it seems you just need to find what works for your team and continuously work on improving on it. What might work today, probably won't work for your team tomorrow so you need to always look at how can you improve your process.

ACM recently had a series of webinars[0] by Ivar Jacobson on Essence[1]. Essence was kind of confusing at first, but it is essentially a language to describe practices from the different processes. The idea is that you can build up a library of the various practices in your company and allow teams to pick their own and evolve their process by swapping out practices that just don't work out. Essence seems like an interesting idea, especially if it allows teams to create a development process that fits them.

[0]: [https://www.sigsoft.org/resources/webinars.html](https://www.sigsoft.org/resources/webinars.html)

[1]: [https://www.ivarjacobson.com/services/what- essence](https://www.ivarjacobson.com/services/what-essence)

<comment> Const-me I have decades of industry experience and I mostly agree.

> find what works for your team

For the combination of team and project. Different software projects need to take very different tradeoffs in how they managed. Use scrum in aerospace for flight control, and people will die. Use scrum for system software, and you'll have hard time delivering quality and performance, system software often requires non-trivial amount of engineering. Implement NASA's best practices when working on videogame or web app, and you'll blow budget.

This article is from 2002 but still good: [https://www.joelonsoftware.com/2002/05/06/five- worlds/](https://www.joelonsoftware.com/2002/05/06/five-worlds/)

</comment></comment><comment><USER39> I'm doing Kanban right now at my job and, I have to tell you, it's so _liberating_.

I hate artificial deadlines (i.e., sprints). Kanban let's you focus on the work without all the process distractions.

</comment><comment><USER40> From all the comments, I see that arguments are there both ways. I also understand that we should follow a process that bets suits the business. I would really like to know how we could set up an Agile process provided that is what is required.

Is there anywhere this would be documented to explain - a. How an agile process in initiated? b. How an agile process is maintained?

I have been part of a team with mis-applied agile processes -

1\. Requirements change frequently. And not due to users asking for them. More like the Project Managers asking for more configurablity.

2\. Requirements are not thought through. Even the simplest cases.

3\. Changes don't get vetted by users. Instead, we go through another round of requirements!

4\. Every once in a while requirements (and teams) get re-organized, re- planned which puts all the developers off.

I have also been part of a team which focussed on deliveries. This team has been able to write tests and iterate over requirements fast. The satisfaction level of all the developers in the team as well as the project owners were high.

1\. Requirements were phased.

2\. Whatever was required to be done in each phase was thought through as far as possible. Anything that wasn't clear or was more complex to think out was sent back to the project owners / users for clarity.

3\. Code and tests get written. Phase delivered.

Although this process was extremely successful, I don't know if I would call this Agile.

</comment><comment><USER41> I agree that Scrum is fragile but not that it isn't agile.

It's agile up to the point that it is broken, which happens often due to it's fragility. That it is easily broken is an unfortunate but unavoidable consequence of its complexity, and common misunderstandings/misuses.

Scrum is complex because large software projects (large as in number of people, budget and expected velocity) are never simple to manage. Scrum is complex because correct usage can not be read from a book nor gained from a qualification - it requires experienced judgement to pick the optimal usage and apply it to a team and project.

Nothing can beat the effectiveness and efficiency of a single strong developer working on a stream of well considered backlog items. That is engineer nirvana! However many projects simply require more velocity than one person can manage. From here, there is a whole spectrum of processes that should be chosen depending on resources and needs. From my experience, full scrum kicks in once you have four or five engineers on the same system.

Product management is a key point of failure in Scrum, true also with other processes. But it's felt so much more when an entire team grinds to a halt and an iteration fails.

If Scrum doesn't feel agile then you are doing something wrong. This is exactly the question the team should be asking itself at retrospectives (doesn't need to be three questions!). What's changing in your process sprint to sprint? Scrum masters are there to facilitate incremental process changes driven by team members, not a system that doesn't result in agile software delivery.

</comment><comment><USER42> The author had really bad experiences. SCRUM is super agile when done right. Change can be introduced during sprint transitions (reviews, retrospectives and planning) - never in the middle of a sprint. Doing so will kill moral and break the rhythm of the dev team.

SCRUM is meant to be owned by the developers - not management. Shame on companies that hijack and impose such process.

SCRUM gives dev teams rhythm with sprints. Allows them to deliver mini releases of functional software in 2-week increments (could be 1 to 4 weeks too - lenght should be decided during planning). The goal of a sprint is to be decided by the developer and doesn't have to be about the software. Can be about learning, improving as a team or helping team members to grow. Here are a few examples I've seen: \- Measure 5 metrics in Kibana \- Marie-Pier leads sprint review demo \- Try self-merging PR's and measure the results \- No more loose ends Of course, in parallel the team builds and delivers an increment of functional software.

The planning, review and retro rituals are paramount. SCRUM can only work well if those are well planned and executed. The retrospective is particularly important to allow the team to improve themselves. Its an opportunity to change their own process (i.e. change the definition of done).

Contrary to wide belief, story points are not part of SCRUM. Its a mechanism that can be used to gauge the size of work - it should be up to the dev team to decide whether to use them or not. Again dev teams should own that process - should not be imposed by management.

These lessons I've learned in the past two years thanks to an awesome SCRUM evangelist we've hired. I'm proud to say its changed our lives for the better.

</comment><comment><USER43> Relevant: [https://pragdave.me/blog/2014/03/04/time-to-kill- agile.html](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)

</comment><comment><USER44> In my current team, we post our daily status on a slack channel: what we do yesterday and we are going to do today. We try to keep to one or two points. We have remote people so that works out well. Standup is optional. On Monday meetings, each person tell one thing that we are going to do. Sometimes it is two things but the point is to focus.

<comment><USER45> This is the way it should be.

Meetings should only be between business / leads to get scope onto canvas.

If I'm blocked I'll seek out the person who can most help me. I can easily find 5-10 minutes to write out a summary, but on my terms when I'm not in coding mode.

Now, I'm freelancing, likely to be team lead for the company assuming they get financing - and I keep taking notes and reading ways to organize better. We have a ton of work to do, it's a financial mobile app that has 0 tests on the api (I'm single-handedly running the API development Laravel + vue (for some web views)). Money is tight so I'm the only dev on web side and we have 1 ios dev.

The hope is to be full-time at this by Christmas w/ a 6 figure salary (my first +6 figures).

</comment></comment><comment><USER46> Scrum truly does end up being "Waterfall" most of the time, in my experience. I think this is largely because teams or management inevitably get bored with projects and end up shifting priorities regardless.

From what I've seen, projects almost always start out in a requirements/analysis phase because management, stakeholders, etc., need the reassurance. I've yet to see any public-facing project of meaningful size start out releasing _actual_ MVPs as opposed to "big bang" releases.

Design often happens first because engineers don't want to(and sometimes can't) begin coding away and then receive designs that are either counter to their existing work or are unworkable; management usually sides with design because, well, _it looks cool_.

Engineers eventually get coding, but non-automated testing doesn't really occur until later because it can be impractical to have people testing unfinished software. Then there's alpha testing, users break the software, engineers fix bugs, A/B testing of different versions of features, then beta testing, where users again _break the software_ and the engineers fix more bugs.

The project continues to drag on because the first 80% of a project is always the easiest part, and management is always hesitant to release "unfinished" software.

Inevitably, there's a _big bang_ release, by which point management has already gotten bored and has dreamt up other "big ideas" for the team to focus on, at which point the project is, for all intents and purposes, placed into _maintenance limbo_ where bugs are fixed, junior developers place their awful code, and a new "feature" is added now and then to satisfy the marketing department.

Senior developers rationalize the waterfall-like nature of the project, so they opt for "continuous integration", but all that ends up translating to is maintenance limbo without versioning.

The _actual_ next version of the software doesn't get built until after most if not all the original team left, and the original software became "legacy" enough that bugs keep popping up and the new engineers don't want to touch the old code. Management eventually gives in, for better or worse.

Am I wrong? This is what I've seen happen to the vast majority of software projects, all under companies that were either Scrum, Agile, or pretend "Agile". Maybe I've just had bad luck.

I wish more teams could pick and choose what methodologies to use for their purposes, rather than buy into MLM garbage.

</comment><comment><USER47> Said it a million times before - I deal with way more process and paperwork using scrum than I ever did with waterfall. I'm not saying waterfall was an answer, but at the places I worked on it, it did a better job of staying out of my way.

</comment><comment><USER48> The SCRUM guide is not long, it's 19 pages in a large font. If I remember correctly it does not even mention a lot of the processes which make up SCRUM for many teams.

However the article is not wrong, it's too easy to make SCRUM all about the process, without changing anything about interactions, developer empowerment and feedback cycles.

I think the SCRUM doesn't do a good job of putting limits on what is still agile SCRUM and what is not. Maybe because it's written in such a friendly language.

</comment><comment><USER49> The aim of Scrum, and other methodologies tagged Agile, is -- near as I can tell -- to emulate a good programmer with a team of mediocre programmers. Not that all developers working on Agile teams are mediocre programmers, only that the business wants to achieve good-programmer results while still being able to leverage the wider talent pool and lower risk and cost offered by hiring mediocre programmers, so it tends to adopt formalized processes designed to work well with them in the hopes that following the process will make them achieve good results. The process is a formalization of the relationship a good programmer has with their client, which is known to produce good results; therefore, the process must also produce good results by definition (and any failure to produce good results can immediately be blamed on lack of adherence to the process).

Unfortunately there ain't no such thing as a free lunch, and when you emulate you necessarily incur overhead, which can be prohibitively large if you're emulating something powerful -- plus, if you have actual good programmers on your team, they will either quit or start emulating mediocre programmers to remain compatible with your mediocre-programmer process. Either way, you lose the benefits of having them.

</comment><comment><USER50> The problem often is that scrum (or any iterative process) fails when it's not paired with good XP engineering practices. There's constant learning and change on the product side, which drives constant learning and change on the implementation side, the code needs to be constantly refactored to best handle the changes.

TDD/yagni/refactoring allows you to keep your code base nimble. I can't imagine doing an iterative process by slamming features in one after another without refactoring the code as you go to handle what "you now know", or not having good test coverage to support the changes you need to make.

Refactoring also shouldn't be something the PO is aware of, it's not a story, or a 2 month break from feature development. It's part of the job as each story is implemented. Yes, sometimes you don't notice a good way of doing something until some time passes and that area of the code becomes a bigger refactor than usual, just have to deal with it as soon as possible.

</comment><comment><USER51> That's a bit of an easy critic of Scrum on its literal sense rather than a critic on what doesn't work or isn't agile or is fragile. I've seen Scrum badly and imperfectly implemented everywhere I've been, yet I think this is preferable as having a strict interpretation of its principles and processes. I don't care actually if Scrum is intrinsically not agile (or Agile): I think what matters and is actually what's happening is people adopting Scrum with agility.

It has good principles like backlog, sprint and daily meeting. If teams only pick one of those or anything else and that it help them, great! By the way holding solely Scrum accountable for failures is narrowing down the analysis to only one part of all things that can go wrong and have nothing to do with Scrum. That's a cognitive biases concentrate.

</comment><comment><USER52> Reading the comments on this post are truly sad. The amount of "me too" juxtaposed with "actually, this isn't a true scotsman" are truly mind boggling.

I wish there was a prescriptive way to successfully make and deliver software. I have seen very little evidence that there is.

</comment><comment><USER53> Although I have remained sceptical of Scrum, I do find it a bit strange that many of the negative comments about Scum here seems to be related to not doing Scrum (The old, you are not doing Scrum properly). All the talk about managers, and being told what to do in a sprint etc. None of that sounds like Scrum to me. Isn't the whole idea of Scrum about self organising teams (?), independent of management etc. All you have is a Scrum Master to facilitate the process, and a Product Owner (part of the team) who prioritises the backlog because that role has an understanding of what is needed to solve the problem at hand (in terms of functionality needed).

</comment><comment><USER54> Where this stuff really fails (IMO) is when execs throw together a half-baked structure around a project, and throw minimally qualified human resources and a few consultancy firms at it. Knowing that "shit rolls downhill", it's always the developers who end up sweeping up the mess working endless hours trying to make deadlines, ensuring everyone further up the hill looks good to their bosses, while praying that their project doesn't get terminated.

In my experience this seems to be an issue unique to enormous corporations. When I used to work at small / medium-sized companies this never happened.

</comment><comment><USER55> I think that longer term strategic planning is missing from the Agile Scrum manifesto.

Agree with the Software development priority queue part being good thing.

Long term planning was in the waterfall process which does not work that great either since it tends to over focus on planning.

How do you find a good balance between Agile and Waterfall?

I think it can also be different what process works well if you are a startup and need to deliver a MVP minimum viable product as soon as possible. Compared a bit to if you are a long term enterprise company and need to maintain your code base over time. Ie dealing with technical debt from short term solutions vs long term stable.

<comment> jon-wood Strategic planning doesn't belong in a process designed to provide constant iteration on a two week basis. In successful organisations I've worked with strategic planning is one of the things that feeds into the backlog of features to be developed, and runs in parallel to development.

</comment></comment><comment><USER56> In my experience, I was lucky to apply Scrum and Agile correctly so now I understand them and can distinguish between them. In my current job, there are no chances to replicate those conditions and I do not expect Scrum to succeed (although we use a lot of Scrum terms to define what we do).

I think one should have experienced a successful scrum project before being able to criticise it.

Scrum is a tool: you may be Agile without using Scrum or you may find easier to be Agile using Scrum. Doing Scrum does not make you Agile. Scrum is hard and implementing it takes different skills than those proven by individuals who can write code.

</comment><comment><USER57> Honestly, the comments on this thread baffle me. Endless complaining about scrum and everyone who is not a developer is apparently clueless about software. Is this an adequate reflection of reality? This doesn't seem like a very mature attitude. Scrum is a simple framework with only three roles, the development team being one of them - so if the process fails you are (partly) to blame for it yourself as well. Take responsibility!

What's the better alternative? What have you been doing to make things better? The answers to these questions as much more interesting than endless complaining.

</comment><comment><USER58> I searched the entirety of the Scrum Guide ([https://www.scrumguides.org/scrum- guide.html](https://www.scrumguides.org/scrum-guide.html)) and could not find a single reference to "agile". And a quick Google search about the origins of Scrum reveals:

 _In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum._

</comment><comment><USER59> > In other words, it is a very specific and well-defined process. This does > not sound agile and it also does not sound Agile (remember: "Individuals and > interactions over processes and tools")

This is a many times debunked myth about the Agile manifesto. Even the authors themselves explained that "Individuals and interactions over processes and tools" does not mean and shouldn't be taken as "no processes".

Also, agile is not about moving quickly but about being able to easily change direction any time, therefore dealing better with changing environment.

</comment><comment><USER60> Scrum is a communication contract between customers / stakeholders, managers and dev teams. It is a poor cure for social and managerial dysfunction, but it is a cure.

Scrum is a problem when it is mandated and imposed on functional organisations that do better and more fluid communication. This is often done as a way of flexing corporate power and does huge damage.

A key problem is that we do not have ways of auditing and measuring the performance of software teams no matter what methods they are using - <USER3> then this is all anecdote.

<comment><USER61> > A key problem is that we do not have ways of auditing and measuring the > performance of software teams no matter what methods they are using - <USER3> > then this is all anecdote.

Of course we have ways of doing that - one is the code quality, another one is historical performance on agility.

</comment></comment><comment><USER62> I wonder what happened to so many developers that turned them so jaded and cynical towards scrum and project management. So far I've dealt with the good and bad of scrum with a good pinch of horrendous PMs in the mix, but I still came out of it with a positive view of the framework. It is hard to run it somewhat smooth and takes lots of motivated people to accomplish[1], but the result had a positive impact on my day-to-day work.

1 - Some people said that this can be a failing of scrum and I 100% agree.

</comment><comment><USER63> Scrum only works if you need sprints, and you only need sprints if you have non-engineering stakeholders whose mandatory approval can only be attained in one meeting per sprint length.

Some large orgs really work like that, where the approval of one ham-fisted iron-gripped executive is deemed more important than hundreds of thousands of dollars of engineering talent going to waste. I don't think this is very effective but alright then.

Everybody else should just be using Kanban boards with periodic review.

</comment><comment><USER64> Reading all the comments out there, there is some atrocious stuff people call Scrum. I'm not even a huge Scrum fan, but it folks seem to criticize what people do in the name of Scrum instead of what is actually in the process.

The TLDR of Scrum is simple: (product) management gets to set the priority of things every 2 or 3 weeks. After that, we see what got done and check to see if the priorities are still the same.

If the priorities are wrong, don't blame Scrum, blame management. If tech debt is increasing, don't blame Scrum, blame management.

There's no magic bullet to determine what is important, and certainly Scrum Master training won't help an incompetent manager a competent one.

<comment><USER65> I don't think I have ever seen it done as badly as some of these comments. Scrum itself is a very light and quite flexible framework, half of the complaints here aren't even Scrum related. User stories aren't part of Scrum, neither are story points or burndown charts.

Of all the people complaining about Scrum it doesn't sound like any of them have read the Scrum Guide. Symptoms of Scrum are not managers pressuring people at stand ups, squeezing 4 weeks of work into 2 and having a "team" of 20 people. These are symptoms of poor leadership.

</comment></comment><comment><USER46> Has anyone ever tested whether Scrum or Agile _actually_ work better than "Waterfall" for software development?

<comment><USER66> Agile works fine, if you ignore the Scrum hocus pocus. Stick to basic project management principles (work on one project at the time, wrap things up before moving on to the next project, set aside a bit of time for unrelated work) with the stakeholder put at the center of what you're up to.

The problem with Scrum is that it's usually (always?) implemented as serialized waterfall projects with completely arbitrary looking deadlines (i.e. the sprint's length). All too often things get sort of done but not done quite as well as everybody would be happy with. It's stressful for everyone involved and, insofar as I've seen it used, it makes accumulating technical debt even more likely than more traditional waterfall projects.

</comment></comment><comment><USER67> I'm quite amazed by the lack of substance in this article. It takes potshots at certain ideas and processes, without managing to explain these potshots, or even coherently explain the ideas and processes. It is a flimsy opinion piece with no substance, but a clickbait title so everyone ran here to comment.

What a virtuous cycle

</comment><comment><USER68> "To me it seems that one very important part of high quality software development is to maintain a simple priority queue of tasks. The weight is a combination of the value a task provides for the customer / developers and the estimated effort to implement this task."

A.k.a. common sense :)

</comment><comment><USER69> Agile – the only word in the English language that inverses its meaning when capitalised.

</comment><comment><USER70> Scrums point for me is to prepare your development time. Talk about the issues, prepare the issues, ask the client, make a mock-up and then implement in code.

Usually it's hack together something and see if it sticks, which is awful.

</comment><comment><USER71> just to offset a bit about scrum being bad: I have used SCRUM over 15 years to run teams and it worked. Most of the problems I am hearing on here are culture problems and no process can fix that. Regarding planning, a day per scrum is normal - sometimes longer, you have to use your judgement to determine when to move from design to implementation. Also, heavy use of spiking stories to learn enough to create the right design is important

<comment><USER72> Can you explain a little bit more about your "spiking stories" and how you use them?

</comment></comment><comment><USER73> The best of agile can be summed up in one piece of advice: "Create short feedback loops". Nail that and you can't go too far wrong.

</comment><comment><USER74> > _" We are simply caught in a rat race and not able to make a short break in > order to look at and learn from all the things that happened around us, > maybe even before our time."_

But isn't that exactly what Scrum wants you to do? After every sprint, you spend some time to reflect, look at how you're working, look at the bigger picture, etc.

Scrum is by no means perfect; it's a tool, not the infallible silver bullet the author wants it to be. If you misuse the tool, you're still going to get wrong results, but that's the same with every other method.

The real question is: is there a better way to do it that can easily and reliably be implemented by large corporations? I think the popularity of Scrum is probably due to it being more successful than what was used before.

It might not be truly Agile, but for large corporations, being truly Agile may be a bit much to ask. They need reliability and reproduceability, and that means they're always going to need some focus on processes and procedures, and can't always rely on people who might leave or have something happen to them. Not that Scrum is always a good fit for those processes and procedures, but it does help make it appealing for large companies, and at least it puts a good part of the process in the hands of the people who will be using it.

tl;dr: Scrum is not perfect, but what is?

</comment><comment><USER75> uh oh, is this the one article that will make people go "A-HA, told you so?" #confirmation-bias

and, I never saw so much interpretation of what something should be as with Agile.

not everyone is entitled to say or mean something, that includes myself and this post.

</comment><comment> a-dub "ahh-gee-lay! must be italian!"

</comment><comment><USER76> Scrum is micromanagement. I think it's as simple as that.

<comment><USER77> no this is completely and entirely wrong.

on the contrary: you have a PO in charge of communication and priorization of features and a dev team in charge of developing- no manager on top...at least in theory...

</comment></comment><comment><USER78> This is very light on specifics? What, exactly, _is_ fragile about Scrum? Where does it break down, and what can I do to prevent it from breaking down?

Without that info, this just feels like buzzword bingo, a la "What should I write about to stir the pot today?"

</comment><comment><USER79> Reminds me of this goto conference talk from one of the original Agile developers "pragmatic" Dave Thomas.

Speaks a lot bout what agile truly is and how scrum is a very large mismatch.

[https://youtu.be/a-BOSpxYJ9M](https://youtu.be/a-BOSpxYJ9M)

</comment><comment><USER80> You may find this very much relevant: [https://www.youtube.com/watch?v=OOAMNOso46g](https://www.youtube.com/watch?v=OOAMNOso46g)

</comment><comment><USER81> Agile itself is pretty bad too. "Responding to change over sticking to the plan" is pretty much the single biggest reason why I see projects fail.

<comment><USER82> I think the key motivation of agile is the recognition that the plan made in advance is often _not right_.

If completing "the plan" is seen as success, then of course sticking to the plan is the best way to success. But if maximizing business/user value is the success, then "no plan survives first contact with the enemy." (I don't like "the enemy" concept, but this is a famous quote that gets across the concept).

And I think the reason why "agile" fails is because many actors in many organizations find they are effectively rewarded for "completing the plan" regardless of business/user value, indeed.

<comment><USER81> This is just not accurate. The types of changes thrown in after early requirements gathering are most often coming from product managers and executives, not from customers and not driven by genuine feedback or budget constraints, etc.

"Sticking to the plan" does not mean rigidly enforcing zero changes, but rather means keeping a commitment to the general scope and direction that was mapped out. Compromises should require extraordinary hard evidence before being accepted.

This is really why Agile as a general set of guidelines is so easy to subvert and ends up being a misused tool in most every situation where Agile is deployed (Scrum of otherwise).

Project management guidelines need to start out by specifying a way that quality is strictly disallowed from being subverted by competing interests that lobby for changing the plan.

If a set of software project management guidelines doesn't start out with an unchallengeable quality-above-all-else mandate that creates policy barriers to the natural entropy of different interests trying to lobby for why their preferred change has to be made, then it's doomed to just get politically subverted.

Doesn't matter if it's Agile, Waterfall, extreme programming, whatever.

"Sticking to the plan" in the sense of setting up preemptive, high-cost barriers to anti-quality modifications to what was agreed is _the_ thing.

</comment></comment></comment><comment><USER83> Nothing can replace Will and Wisdom

</comment><comment><USER31> To think of scrum as a process is wrong. It's actually an organizational pattern language. The idea is that social interactions are a complex system and there are patterns of interactions which, from experience, seem to work in certain contexts.

[http://www.scrumabok.org/](http://www.scrumabok.org/)

It's not even software specific. Which is actually a strength.

Example, one common misconception is the daily standup is a status meeting. In fact you are supposed to replan in standup, it's a tiny planner. Not sure how you can call the ability to pivot every day not agile.

EDIT: Unpopular option, software quality is poor and it has nothing to do with scrum.

<comment><USER36> No.

Agile is a subset of TPS (toyota production system)/Lean applied to software.

<comment><USER31> And scrum? TPS is explicitly an influence on scrum.

<comment><USER36> Scrum is just an instance of the agile manifesto. TPS/Lean > Agile > Scrum.

Kanban for example is another instance of the agile manifesto.

<comment><USER31> Scrum existed before the agile manifesto. It's probability more accurate to say Agile is a mix of those things.</comment></comment></comment></comment></comment>


Ask HN: How to prepare for a Google interview? - <AUTHOR>

I just have a phone interview set up at the moment. I was recommended by a former manager of mine. I do NOT have a CS degree but for some reason they want to interview me anyway. (this is an engineering position.) <comment><USER2> Google does an interesting engineering interview. The best advice I can give:

1) Read the first couple chapters of Introduction to Algorithms (Cormen et. all) enough times to know it cold. Something in there will come up. 2) Dedicate a day or so to browsing pertinent Wikipedia articles. Simply read as much as you can.

The former gives you some depth. The latter, breadth. Outside of off-the-wall Wikipedia articles, you should not be discovering anything radically new. If all goes to plan, you should be able to answer the bulk of the straight engineering questions. If you're lucky, one of them will click with a Wikipedia article you've just read. See: Fragmentation, Skip Lists, Virtual Functions, whatever. Read lots. Even if emulated, breadth counts.

If you get lost on step 1, this isn't the job for you (right now).

Good luck!

</comment><comment><USER3> The Google recruiters recommended me this Steve Yegg post: [http://steve- yegge.blogspot.com/2008/03/get-that-job-at-goog...](http://steve- yegge.blogspot.com/2008/03/get-that-job-at-google.html). Also take a look at his posts on Amazon recruiting, as I found they were very relevant.

Learn Big-O notation for various algorithms

One thing that was recommended to me and I didn't do was the Topcoder practice rooms. In retrospect I think that could have been useful.

</comment><comment><USER4> Check this link out: It might help you.

[http://www.amazon.com/Cracking-Coding-Interview-Fourth- Progr...](http://www.amazon.com/Cracking-Coding-Interview-Fourth- Programming/dp/145157827X/ref=sr_1_1?s=books&ie=UTF8&qid=1284344642&sr=1-1)

</comment><comment><USER5> Practice writing code on a whiteboard.

Learn your algorithms.

Learn "O()" notations.

As well as the above they seem to look for a good GPA, good school, and a record of having achieved things.

</comment><comment><USER6> Did you google "Google interview"?

</comment><comment><USER7> you dont want to work there.

<comment><USER8> Please elaborate.</comment></comment>


Show HN: The prime knots in 3D - <AUTHOR> http://github.prideout.net/knotgl/ <comment><AUTHOR> I was inspired to make this after reading "The Knot Book" by Colin Adams. If you click "Rolfsen Table" at the bottom, you'll see the entire gallery.

<comment><USER2> Mesmerizing...really well done. Thanks for sharing, and for the book recommendation!

</comment></comment><comment><USER3> This is cool, but what's the point of using the bounce easing? It just makes you wait an extra second before you can get a good look at the new model.

<comment><AUTHOR> You're right, I sorta overdid it with the easing animation.

<comment><USER4> I agree you overdid it. Also on the table view, the highlighted row spins too fast.

But other than those minor quibbles, it's neat!

</comment></comment></comment><comment><USER5> This is beautiful and really well done. I especially like how the light reflects naturally as the knot rotates. How did you achieve that effect?

<comment><AUTHOR> Thanks! The fragment shader performs simple lighting with one stationary point light that has ambient, specular, and diffuse components. There are actually no true reflections, although that would be fun thing to work on.

</comment></comment><comment><USER6> The bounce is too hard. Also, what do the numbers mean?

<comment><AUTHOR> Agreed! The numbers are the Alexander-Briggs identifiers for the prime knots:

\- The big number is the number of crossings.

\- The subscript is its officially designated index within the set of knots that have the same number of crossings.

\- If there's a superscript, then it's a link, and the superscript represents the number of components.

<comment><USER6> Ah, cool. I was thinking that maybe 4sub1 should be a '3'.

Any chance of being able to rotate the model using a mouse/touch?

</comment></comment></comment><comment><USER7> Where's the unknot?

<comment><AUTHOR> Yes, it's sacrilege, but I omitted the trivial knot from the main table! You can get to it in a roundabout way, by clicking any other knot in the top row (e.g., the trefoil).

<comment><USER8> What about the empty link?

</comment></comment></comment><comment><USER9> Very nice work.

</comment><comment><USER10> They are pretty</comment>


<input type="country" /> - <AUTHOR> https://shkspr.mobi/blog/2017/11/input-type-country/ <comment><USER2> I have my doubts as to whether a generic solution solves this.

The author notes some issues, like using it for place of birth. Now you need a temporal list for "countries that existed in year XYZ".

There are similar issues for shipping. Not everyone ships everywhere. If the list is abstract and unknown to me, how do I whitelist/blacklist? Am I supposed to know that Scotland exists in the list or not? What if it's for a passport input? Does Scotland have it's own passport? How do I deal with Taiwan without pissing off Chinese web site visitors?

Tldr: The list depends on context. I'm skeptical that a centralized list could deal with commonly used contexts.

<comment><USER3> An input list of all current passport issuing countries would be useful. The Scotland problem doesn't arise as they don't issue passports (the UK does).

<comment><USER4> what about taiwan? what about taiwan if you're in china...?

<comment><USER2> I believe Palestine has a similar issue. They have passports, but few countries recognize them.

</comment></comment></comment></comment><comment><USER5> There was an excellent article[0] in Smashing Magazine several years ago that dealt with some of the complexities of country selectors.

For someone who lives in the UK, you never know whether a list will have United Kingdom, Great Britain or England in it (I've come across all three), and similar problems exist for countries that are known by more than one name (eg Netherlands vs Holland).

And some sites break sorting by pushing certain countries to the top of the list and breaking sorting completely.

There isn't a completely right answer, a standardised country selector might work in some (most) circumstances for most people, but what if my list needs Czechoslovakia or Zaïre? Then, a "simple" problem becomes much, much, much more complex.

[0] [https://www.smashingmagazine.com/2011/11/redesigning-the- cou...](https://www.smashingmagazine.com/2011/11/redesigning-the-country- selector/)

</comment><comment><USER6> Classic simple problem that's impossible to solve.

The thought that web browsers support could solve this problem speaks volumes about the kind of rate people _think_ software gets updated. You could never trust input=country to be supported much less up to date thus it will always be poly filled by some library. So why the false hope?

<comment><USER4> this would have to be supported on the network level, something like DNS with temporal querying for 'i was born in yugoslavia' type of forms.

<comment><USER7> But by the time this happens - there's a huge probability our browsers will no longer be rendering any HTML.

</comment></comment></comment><comment><USER8> Stopped reading at "mansplainers".

<comment><USER9> How does this contribute to the discussion?

<comment><USER10> It was said in the original article, so I'd ask how that quip contributes to their own point beyond inviting this exact conversation. It's a very socially charged statement.

Do you also expect people to overlook a quip about gun control laws while explaining how monads work in Haskell, or is that conversation off the table because you embedded it inside another topic?

<comment><USER9> I honestly don't think the writer was trying to 'invite this discussion', she made an offhand comment about her experience. I think people are _seizing_ this as an _opportunity_ to talk about their pet peeve.

The comment doesn't add to the discussion about whether a country field would be useful or how it could be implemented _at all_.

But anyway did you read the twitter thread? The writer proposed standardizing a common function so everyone wouldn't have to roll their own.

A number of guys responded with 'here's how to roll your own' as if she wasn't intelligent enough to do that herself (and completely missing the point of the tweet).

Do you have a better word for that behavior?

It wasn't an offhand quip like your gun control example, it directly related to the tweet she was talking about.

And yes, I would think most people could read an article without freaking out that the two words 'gun control' were in there if they were off topic.

It seems sad to me that seeing one word in an article is enough to derail the entire conversation because some people don't like it. It's not like it was a call to violence or something like that.

<comment><USER11> The better word is "asshole". I've had similar condescending conversations from women when I was at the laundromat because I guess they assumed a guy would only be doing laundry in a direction circumstance. I didn't need to come up with a gender specific word for behavior that any random human is likely to exhibit.

As for this specifically, I doubt they corrected her because she was a woman. Ask any question on stack overflow about a specific edge case and you'll get a few people answering immediately about the general case and not your specific problem.

</comment></comment></comment></comment></comment><comment><USER12> Nice idea, but she outlined more than enough reasons not to do it. Political (Israel-Palestine, China-Taiwan, Ukraine, etc).

In my limited experience with automating international shipping I seem to recall UPS treats Guam, Puerto Rico, and US Virgin islands as countries (and our local CRM treated them as states).

There are so many controls that HTML is missing - date pickers, menus, menu flyouts etc.

</comment><comment><USER13> Just do longitude and latitude. Show a map of the earth and let them drop a pin.

There is no reasonable way to get the world to agree on a single list. I doubt you could get browser developers to agree on a single list. For example Apple listing Taiwan in Safari could get Apple kicked out of mainland China. There is simply too much politics here to be tenable.

<comment><USER14> I wonder how many people could find a country on a world map and drop a pin. I bet it's not too many.

<comment><USER15> It would be much higher given it's their _own_ country.

<comment><USER16> You might be horrifically surprised.

</comment></comment></comment></comment><comment><USER17> One paragraph into the article:

> while also marvelling at the witless mansplainers

Yeah, let's make every discussion about gender, shall we?

How about no?

<comment><USER18> I read that, stopped caring, and closed the tab.

</comment></comment><comment><USER19> Good discussion, and it is certainly very nuanced.

The trouble of the developer having to create this list themselves is the reason I made [http://devdata.io](http://devdata.io) \- so you could at least have an easy starting point for all this data that is basically just copy/paste.

</comment><comment><USER4> timezones are a similar topic in the context of managing them, except there's less politics involved. i don't see how a global solution would look like, but i'm sure china will want a different list than russia and the US will want a different list from both of them, and that's only 3 countries out of 199 or 249 or however many are there at the moment (and then the temporal aspect comes into play.)

<comment><USER20> Timezones are downright trivial compared to this one, even if the heads-up can be _very_ limited there's a central well-maintained database of them, and they have fairly low context-dependence: some historical context (timezones can "move around") and the socio-political context is limited to _changes_ to timezones.

</comment></comment><comment><USER21> Regarding the place of birth issue, I have never used the country I was born with when some form asked for birthplace. Always used the present state, i.e. in what country is the place I was born at.

Is that not common? Would you expect someone to write down GDR, USSR, or even Constantinople? Or is it again the same issue that people want to use what they like?

<comment><USER22> One use-case I can see where this would come up: ancestry/genealogy websites. Someone's grandparents may have been born in the Soviet Union, not in the modern Ukraine, from a cultural-historical standpoint.

</comment></comment><comment><USER23> There is web component for that [https://www.webcomponents.org/element/Protoss78/country- sele...](https://www.webcomponents.org/element/Protoss78/country-select)

<comment><USER24> It's yet another tangent in this topic, but there's something that bothers me here, and in many things that try to handle multiple languages.

There are _47_ lists of countries in French (that's just an example, I guess English and Spanish have as many of those) in the project that provides them [0], including half a dozen or so just for different regions of France.

As far as I can see, almost of them are _exactly identical_ except for the Canadian one (which has "Saint-Vincent-et-les Grenadines" instead of "Saint- Vincent-et-les-Grenadines" among other things).

For English, en_US and en_UK have differences as meaningful as "Wallis and Futuna" vs. "Wallis & Futuna". Arabic has 28 different versions, all strictly identical.

English, French, Spanish and Arabic "version" alone make up 33% of all content in the repo. What purpose does this serve? Who maintains these largely meaningless lists? Who chooses which languages make it to the list, and which regions do?

I'm as puzzled by that as I am by the choices people make about what countries make it to their list of countries in select lists.

[0] [https://github.com/umpirsky/country- list](https://github.com/umpirsky/country-list)

</comment></comment><comment><USER25> I'm mostly just impressed that HN allows brackets in the title...

<comment><AUTHOR> I had to edit and replace them with HTML entities, at first they were just stripped.

<comment><USER25> Okay, now I'm less impressed :).

</comment></comment></comment><comment><USER26> This post looks funny in the Digg RSS reader: [https://i.imgur.com/TNASB3p.png](https://i.imgur.com/TNASB3p.png)

</comment><comment><USER27> now tie that to a SaaS that helps you manage those countries</comment>


Gold iPhone Just Sold On eBay For $10,100 - <AUTHOR> http://item.mobileweb.ebay.com/viewitem?itemId=111174869600

<comment><USER2> Sorry, but I'm skeptical about this because it defies logic.

I'm not an eBay expert, but it seems unusual that the bid jumped from 2,500 to 10,000 in one big jump like that.

Is this a fake bid? Some kind of weird spam or marketing stunt?</comment>


Shop.lenovo.com compromised - <AUTHOR>

URL: http://shop.lenovo.com/<p>So I don't know what happened yet, but it's an "interesting" slideshow and soundtrack to say the least. <comment><USER2> I know it's bad karma, but I really hope this was due to some kind of problem with their certificates...

</comment><comment><USER3> [http://thenextweb.com/insider/2015/02/25/lenovos-website- was...](http://thenextweb.com/insider/2015/02/25/lenovos-website-was-hacked- and-its-kind-of-perfect/)

</comment><comment><USER4> If those are actual pics of the Lizard Squad, that was incredibly dumb.</comment>


Why exercise will change your life - <AUTHOR> http://seattletimes.nwsource.com/html/pacificnw/2018312089_pacificpfitlife10.html

<comment><USER2> After seven years and an added 80lbs I've started exercising regularly for the past month. I get more restful sleep, I have more energy, and I'm happier. I liked that the article addressed the typical complaints and excuses that people have when first getting into an exercise routine.

I've lost 20lbs since I started about 30 days ago and would like to sing the praises of the FitBit pedometer/website and Scooby's Workshop (scoobysworkshop.com). The FitBit is sleek and has a great overall UX (in my opinion). I really like Scooby's website because his tips are practical and fact-based. Besides, who can't like a jacked 50yr old engineer?

</comment><comment><USER3> This site pops.up an ad to force install antivirus for your phone.. steer clear.</comment>


Overwhelming Majority Say Time to 'Decouple' from China - <AUTHOR> https://www.forbes.com/sites/kenrapoza/2020/04/27/overwhelming-majority-say-time-to-decouple-from-china/#8307d9677a2b <comment><USER2> Good luck when people realize that the only reason we get all this cheap/affordable tech is because people in China are working long days without any safety regulations for a few dollars a day.

</comment><comment><USER3> With the non-stop anti-China campaign in the media, it's no wonder. Working up this level of irrational hysteria about China is dangerous to the peace.

</comment><comment><USER4> Smart people have been saying this for years

</comment><comment><USER5> Nah, it's time for the world to decouple from the US.

</comment><comment><USER6> what other population would we exploit for cheap gadgets?</comment>


The Icon Programming Language - <AUTHOR> http://www.cs.arizona.edu/icon/

<comment><USER2> Most of the Icon books are free online, and the one detailing its implementation (Little Icon?) is an excellent general purposes introduction to virtual-machine implementation.</comment>


Using Gephi (open source graph vis software) to visualise Lanyrd's topic data - <AUTHOR> http://lanyrd.com/blog/2011/visualising/

<comment><AUTHOR> Here's Matt Biddulph's resulting visualisation, it's pretty fascinating: <http://www.hackdiary.com/misc/lanyrd-tags/>

The interactive itself uses the Seadragon Ajax library: <http://expression.microsoft.com/en-us/gg413361></comment>


Show HN: Appster – Free Bootstrap 4 App Landing Page Template - <AUTHOR> https://wireddots.com/products/appster <comment><USER2> Total requests: 30 Size: 1.149,02 KB Transferred Size: 539,24 KB Time: 6,53 seconds

That's on a wired 50 megabit connection, I don't want to know the load time on mobile. Good job on an overblown landing page!

Related thread: [https://news.ycombinator.com/item?id=15031814](https://news.ycombinator.com/item?id=15031814)

<comment><USER3> Please be respectful of other people's work. The same criticism could have been framed in a much less toxic manner.

The author has clearly put a lot of work into this, and theres a lot more good things to say about it than there are flaws.

For example, it looks beautiful, will certainly help many people, and I, personally, will be happy to learn from it and use in my own future projects. Even though page size can be improved, author did a great job, and I don't want him to be discouraged by your nitpicking.

So don't be a dick.

<comment><AUTHOR> Hey, thank you. Glad, you like it.

I agree with you on page size/load time. It is just a demo landing page and not a final product. There are plenty of ways to improve the page metrics.

<comment><USER4> Since the actual size is tiny, tried using webpack to combine some of the resources. Saved ~40% of that size with minification and dead code removal, and saving that many requests meant that it takes a tenth of the time to load.

Might recommend you try it too for releases, as a lot of people might not know how & will use this as is.

</comment></comment></comment></comment><comment><USER5> There are a few places that don't look great if you look at the demo on mobile. There's too much padding on the bottom of the header nav, the app store logos don't have any margins, and the 'Unlimited Features' title is right up against the image of the phone.

<comment><AUTHOR> Thank you for the feedback. I'll fix soon.

</comment></comment><comment><USER6> The app is nice for the promotional site. It is light and beautiful.

<comment><AUTHOR> Glad, you like it ;)

</comment></comment><comment><AUTHOR> Wow, Appster is downloaded 210+ times in just 3 hours. I didn't anticipate this. It was a fun project I created while learning Bootstrap 4 but it turned out a useful app landing page.

I would love to see how you are using it. Just send me a tweet at [https://twitter.com/attacomsian](https://twitter.com/attacomsian)

<comment><USER7> It looks very nice. By the way, why didn't you make a landing page for Appster with Appster?

</comment></comment><comment><USER3> Awesome work, thanks for sharing!

Bookmarked it, should come in handy when I'm building my next landing page =)

</comment><comment><USER8> Just a quick grammar tip: "A beautiful screen capturing app you can trust on" should say "you can trust" or "you can rely on."

For that matter, I'd probably refer to it as a "screen capture app" instead of a "screen capturing app."

<comment><AUTHOR> Yes. You're right. Didn't pay much attention as it was supposed to be a dummy text.

<comment><USER9> This is exactly why you need to use Lorem Ipsum otherwise visitors spend their time focusing on the text (I was trying to work out if it was a theme or an app you were pushing)

<comment><AUTHOR> I'll replace the text with Lorem Ipsum.

</comment></comment></comment></comment><comment><USER10> I can't load the webpage; is it down for anyone else? Google cache returns 404.

<comment><AUTHOR> Server crashes... ! Just restarted. it is live again.

<comment><USER10> Cheers, it's back up again.

</comment></comment></comment><comment><USER11> Why use alpha when the beta of Bootstrap 4 is out?

<comment><AUTHOR> Beta is released few days ago. I built Appster a couple of weeks ago but released it today. Will update it to Bootstrap 4 once it is available.

</comment></comment><comment><USER12> Great and useful work. Bootstrap 4 is still in beta, do you plan to continue support, taking into a count possible api changes?

<comment><AUTHOR> Glad, you like it. Yes, I will upgrade it to Bootstrap 4 once it is released.

</comment></comment><comment><USER13> Bootstrap templates are Show HN material now?

<comment><USER14> Bootstrap templates require a non-trivial amount of work. Why should they not be?

</comment></comment><comment><USER15> You may want to add default margins to some elements. On mobiles the buttons, images etc. are overlapping.

<comment><AUTHOR> I'll fix. Thank you for the feedback.

</comment></comment><comment><USER16> Unfortunately this is down for me again

<comment><AUTHOR> I'm sorry for the trouble. i just upgraded the server.

<comment><USER16> No problem and thanks for the work - this is useful!

</comment></comment></comment><comment><USER17> What theme is wiredots built on?

<comment><AUTHOR> It is Built on Wired UI kit (a Bootstrap 4 UI kit). I'll release it for FREE in coming weeks ;)

</comment></comment><comment><USER18> Beautiful work!

<comment><AUTHOR> thank you.

</comment></comment><comment><USER19> This is on the front page, Seriously?</comment>


Think mathematics is (just) a language? Think again. - <AUTHOR> http://www.blog.republicofmath.com/think-mathematics-is-just-a-language-think-again/ <comment><USER2> The argument seems very thin here. How is the mathematical equivalent of "blinding me with science" any proof that mathematics is not a language? I'm not arguing one way or another, but this does not demonstrate the proposition made in TFA.</comment>


Startup Quote: Sean Rad, founder, Ad.ly - <AUTHOR> http://startupquote.com/post/5844215757

<comment><AUTHOR> The compromise of two visions don't make a right.

\- Sean Rad (@seanrad)

<http://startupquote.com/post/5844215757></comment>


Amazon restricts The Lego Movie, Transcendence sales over Warner Bros. contract - <AUTHOR> http://arstechnica.com/business/2014/06/amazon-flexes-its-muscles-again-in-new-contract-dispute-with-warner-bros/

<comment><USER2> Amazon needs to be destroyed. They use their position to completely strangle businesses into bad contracts (or just put them out of business if they don't comply).

I wish there was a better alternative out there.</comment>


Fanout.io Emerges From Private Beta, Provides Real-Time Push CDN - <AUTHOR> http://techcrunch.com/2014/04/10/fanout-emerges-from-private-beta-provides-real-time-push-service/

<comment><USER2> Reading that PR release and their landing page, there are so many unanswered questions.

How is this different from PubNub or Pusher, which also provide push as a service? What is the pricing for the service? Are there first-party libraries for popular languages?

<comment><USER3> Hey there. The main difference is that Fanout is invisible to clients. You explicitly choose the data transports and formats. This makes it well-suited for fronting public APIs, since you're in control of the interface. Our codebase is also open source.

This article goes into good detail about the reference implementation for our HTTP transport: [http://blog.fanout.io/2013/04/09/an-http-reverse-proxy- for-r...](http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for- realtime/)

Although it could be made more apparent, we have Python and Node libraries in our GitHub: [https://github.com/fanout/](https://github.com/fanout/)

Also RealCrowd developed a .NET library: [https://github.com/realcrowd/grip.net](https://github.com/realcrowd/grip.net)

<comment><USER4> kudos for being opensource.that's in my opinion the right model.try localy then scale in the cloud!

</comment></comment></comment><comment><USER5> Cool, but what does this have to do with OneBusAway? (the service depicted in the monitor in the photo accompanying the article).

<comment><AUTHOR> (Fanout guy here)

We're not sure! We're not working with OneBusAway, but I think the author of the article was trying to convey a sense of realtime with that image.

Sorry for the confusion!

<comment><USER5> No sweat. I'm actually one of the developers on the iOS version of the app and was just sort of surprised to see it at the top of the article!

</comment></comment></comment><comment><USER3> We're here if anyone has questions. :)

<comment><USER6> Do you have any information about pricing?

<comment><AUTHOR> Currently free for testing or low volume production use. We'll be rolling out our pricing page in the near future!

We really want this to be the easiest and most cost effective way to scale realtime so if you have a specific use case in mind we'd love to hear more!</comment></comment></comment>


Why doesn't the NiceGuy.A virus exist? - <AUTHOR> http://i.imgur.com/6gyAn.jpg

<comment><AUTHOR> I'm fairly certain this is a fictional virus. But, I don't think I've ever encountered anything similar IRL. I wonder why such a virus doesn't exist? Perhaps the same people who might make a "nice virus" have an ethical dilemma about writing a virus in general, regardless of it's intended purpose?

In any case, I'd totally get behind a virus that forced an IE6 upgrade! :)

</comment><comment><USER2> It would probably be illegal to release such a thing regardless of intentions, so the risk would seem to exceed the reward.

</comment><comment><USER3> If it actually does what it says it does, thats awesome...</comment>


MIT Blockchain Systems Consortium: Scalable AI and Blockchain for Humanity - <AUTHOR> https://cryptosystems.mit.edu/mit-blockchain-systems-consortium-scalable-ai-blockchain-humanity <comment><USER2> I always feel like people are trying to launder blockchain, which appears to me to be mostly useless, with AI, which is highly useful. I fail to see how the two technologies are related in any way.

<comment><USER3> Trendy at the same time. They're contemporaries. Related by circumstance.

It's all just marketing.

<comment><USER4> The block chain has fundamentally reinvented the way startups fleece investors.

</comment></comment></comment><comment><USER5> Quantum AI blockchain technology on renewable energy will save the planet. Mark my words.

<comment><USER2> The most buzzwordy thing I heard from a blockchain guy was from Vinay Gupta, of Ethereum fame. He said quantum computers can solve the economic calculation problem, so we can get Quantum/Blockchain/AI socialist central planning.

<comment><USER6> Unironically, we can already solve the calculation problem with standard computing techniques right now.

<comment><USER2> To match the performance of a market economy, wouldn't that require modelling agents that themselves have access to the same computing techniques you have?

</comment></comment></comment></comment><comment><USER7> From the Home page

> The MIT Blockchain Systems Consortium will conduct anti-disciplinary > research

> What are the next things that were always impossible, until suddenly, they > not longer are?

At the risk of sounding facetious, have you considered an automated proof reader?</comment>


JavaScript Has Its Place, But Not Every Place - <AUTHOR> http://accidentaltechnologist.com/javascript/javascript-has-its-place-not-every-place/

<comment><USER2> Increasingly, the places people want to run your code are most easily addressed by browsers. And the only language that runs in the browser[1] is JavaScript.

I'm not saying the current state of JS development is great.

[1] The Browser being a nebulous term encompassing multiple hardware profiles, operating systems, and browser implementations</comment>


New iPad Commercial. It's Almost Manly. - <AUTHOR> http://www.crunchgear.com/2010/05/13/crazy-powerful-and-magical-where-do-i-sign/#comment-1275477

<comment><AUTHOR> I was taken aback by how manly this commercial was from apple. If you just listened to it without looking at it it could almost be a truck commercial. This is a very divergent strategy for apple, even though the apparently made a similar ad for th newton, but even that one didn't sound as manly.

Does Apple feel a need to attract men with this product? Are they afraid only women will buy it?</comment>


Some Code I Deleted - <AUTHOR> https://blog.afoolishmanifesto.com/posts/some-code-i-deleted/ <comment><USER2> Tangent: the post links to [https://bugs.python.org/issue11416](https://bugs.python.org/issue11416)

That bug makes me sad. It was opened in 2011. It's a trivial bug to fix. Two separate fixes were submitted, one with several iterations addressing all feedback. By my count, at least five people have dealt directly with the issue (contributing or reviewing code, providing feedback, etc). Who knows how many folks have been affected by the bug and found a work-around or gave up on it. Meanwhile, a fix ends up just withering on the vine for years.

This is not a complaint specific to Python. I've seen it happen with many projects, both closed and open. What a waste of people's time.

<comment><USER3> If it's trivial and fixes have been offered, why hasn't it been fixed? Is it controversial?

<comment><USER2> I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3.

Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat.

A new patch then came in in April 2016 which has been completely ignored.

I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it.

It still seems like a huge waste of time though.

<comment><USER4> > There was a claim it couldn't go into 2.7 because it was an API change (even > though it was backwards compatible)

But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.

<comment><USER2> Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped.

Maybe you're objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, [https://bugs.python.org/issue22960](https://bugs.python.org/issue22960) added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.

</comment></comment></comment></comment></comment><comment><USER5> _One of my friends is fond of saying "no code is better than no code". I tend to agree. Code is fun to write, but it's such a liability, especially if you have less time than when you initially wrote it. This is why I think so much time can be spent on automation or documentation; because it helps out future me. But the most foolproof way to win is to just not play, given the option._

In my experience, you sometimes need to write code in order to realize that you didn't need to write it in the first place. Maybe that's one of the things that separates a senior developer: they know what code _not_ to write.

<comment><USER6> Deleted code has no bugs. Similar to the old phrase ___' Dead men tell no tales'_ __

</comment></comment><comment><USER7> Re Python netrc bug, you shouldn't put valuable passwords in ~/.netrc:

[http://jwilk.net/blog/20131104-netrc- security](http://jwilk.net/blog/20131104-netrc-security)

<comment><USER8> Sure, there are a _lot_ of reasons not to use netrc for valuable passwords, starting with "don't put valuable passwords in plaintext especially in a predictable location"!

I use it quite sparingly. At work, sometimes I need to make a large number of calls to a password-authenticated API. My approach there is to `sudo mount -t tmpfs -o size=5M tmpfs ~/tmp/secret/`, put a .netrc in there, and use curl's `--netrc-file` option to point to it. When I'm done, I umount the ramdisk. The password never hits the disk unencrypted, modulo swap.

<comment><USER7> You could make curl read netrc from a pipe.

Something like this should work:

      #!/bin/bash
      password=$(...) # replace with code to extract password from the the password manager
      generate_netrc()
      {
        printf 'machine www.example.org login foo password "%s"\n' "$password"
      }
      curl -v --netrc-file <(generate_netrc) http://www.example.org

No need for sudo and no risk of hitting swap. :-)

</comment></comment></comment><comment><USER9> Gmail IMAP is slow as hell. A self-hosted IMAP server is quite fast.

</comment><comment><USER10> Is there some specification that covers what it is supposed to mean if a host is listed more than once in .netrc?

The man page for netrc on most Unix or Unix-like systems that I checked includes this for how the "machine" token is handled:

> Identify a remote machine name. The auto-login process searches the .netrc > file for a machine token that matches the remote machine specified on the > ftp command line or as an open command argument. Once a match is made, the > subsequent .netrc tokens are processed, stopping when the end of file is > reached or another machine or a default token is encountered

That specifically talks about ftp's use of .netrc, and as described only the first entry for a host is ever processed.

I can think of two ways to take that, from the point of view of a programmer thinking of using .netrc for a program that is not ftp.

1\. .netrc was designed for ftp. If I'm going to use another programs' file I should use it exactly like it is documented to use it...so I should only look at the first matching machine too.

2\. .netrc was designed for ftp, but it is explicitly documented as only looking at the first matching machine. What that tells me is that I can go ahead and tell my users to use .netrc for my program too, and if they need different credentials for my service than they do for ftp on a given machine, go ahead and make a separate machine entry for my program. Just make sure it is not the FIRST machine entry for that machine. I can add some way for them to tell my program which entry to use when there are multiple machine entries that match. Either a command line argument, an environment variable, or since ftp is guaranteed to not process other than the first match I could even add a new token in .netrc that marks my entry.

</comment><comment><USER11> Couldn't you use plot "./out.csv" using 1:2 with lines to have the same line graph with gnuplot ?

<comment><USER12> For sure! I actually think I _prefer_ the points over the lines, since the lines make you think that there is data where there isn't.</comment></comment>


What is the most cost effective way to mine Crypto Currency? - <AUTHOR> What is the most cost effective way to mine Crypto Currency?<p>Cloud Mining? Buy the specialist hardware (Asic etc)? or use the CPU & GPU power you already have? <comment><USER2> Before you start, read up. I have the impression you think you can make a quick buck. Mining large scale is expensive and the field is heavily contested.

The biggest cost is electricity. You compete against mining farms in China and wherever electricity is as cheap. Sit down and calculate the cost of electricity per mined unit currency.

Hardware should also be efficient because if you buy lots of servers, heat is going to become a serious problem.

<comment><AUTHOR> Many thanks, I guessed that the electricity would be the main issue. I just wondered if a comparison of the ROIs and efficiencies of the various methods has been published anywhere. Again, thanks for the info.

</comment></comment><comment><AUTHOR> Or other methods?</comment>