skysight-inc/HackerNews huggingface dataset:
I agree that there are individuals and companies who have defined such ridged structure and expectation into their Scrum method that they can no longer be considered an agile approach missing two of the key purposes of agile approaches:

* Individuals and interactions over processes and tools
* Responding to change over following a plan

Now, I cannot say that Scum abstractly is a bad approach to attempting to be more agile. Many of us have employed some form of it with varying degrees of success, but, the expectations on software developers from a business perspective are more rigid for business development and tracability purposes, which can,on occasion, omit the consideration of resource demands and complexities.

Often, i believe, it is that a lack of understanding the purpose of the agile manifesto and the poor implementation of a method at the top level of the developer and managment ladder which is the underlying cause.

In the post, the author cites 3 hour or more meeting where he feels there are too many people there. This would be an item for the retrospective feeding the next iteration, but he only says "Blergh" about the needed feedback.

He states that the standup is more ritualistic, but the point is to ensure each member understands where the sprint stands, inspire collaboration, but really take ownership of the code. It could be that the team size is too big, or that the team really has not taken ownership of their code.

When all is said and done, you have to buy into the Scrum process, the process has to be flexible, and the stakeholders have to not believe it is a magical development method that fixes all the issues of the software development process.
Interesting article but somewhat misleading
The problems that were challenging and interesting back in the Quake era are now just standard commands built into your GPU, and so modern engines have very little in common with Quake's engine.
Unrelated, but I keep wondering if there is a viable market for an install system that is generally less fubarred than WiX Toolset, but still compiles down to MSI.
One can do this 80%/20% split. Not sure if it's mentioned in some official guide or it developed through trial and error.

Usually the 20% is reserved for bug fixing tasks which can't be estimated and therefore can't be included in the Scrum framework.

One of my projects has a "technical backlog" which is actually just a Jira task with multiple subtasks which gets dragged from sprint to sprint. As you can imagine this doesn't work so great from a process/tool perspective, but it gets the job done (i.e. Major refactorings can be and have been performed).

The thing with Scrum is that a lot depends on the PO and SM. If they're open minded and experienced you can get something decent. If they're dogmatic and pray at the altar of Jira, prepare for suffering.
I'm an Impostor
I have no references but common sense. Popper gave the best tool I know to differentiate between proper science and quackery, namely falsification. In order to a theory to be falsifiable, there must be a way to prove the theory incorrect. For example, if I see that the newtonian equation for force, acceleration and mass (F = ma) does not hold, in some circumstances, I am able to falsify the theory.

Now, maybe the most fundamental assumtion of economics is that people are utility maximizers. I see no way how this can be falsified. How can I make a choice that proves I was not maximizing my utility?

This, in itself, is enough for me to be confident that economics is not (yet) a proper science, but a bastard of ideology and mathematics.
When Every Company Is a Tech Company, Does the Label Matter?
Says what, though? I'm just looking for a single sentence that demonstrates the particular usage.
Maybe more correctly: the vast majority of humanity was equal in its wretchedness, poverty, ill-health, and violence; the vast majority of people led miserable, hungry, precarious, uninteresting lives.

Again, I'm not saying we've done all we can do. I'm not saying that many of the rich don't behave reprehensibly. I'm not saying we can't do better. But the question is: How? How can we do better most effectively? I don't think the answer is 'tax global wealth and redistribute' a la Piketty--because that's not what enriched us so over the past 200 years.

So yes, it has gone up and to the right, especially in most recent history--though, because of human folly, there is no guarantee that it will continue to do so.
The Great South American Civilizations – The Aztecs
The Little Prince and The Alchemist. Whenever I make new friends I give them either of these books if they haven't read them yet. These two have changed my point of view significantly -- and I've read them at an adult age already.
If cheap manufacturers were forced to significantly tweak the design, it would become easier to spot a fake, which means expensive restaurants would more willingly pay the difference to get originals.

If everyone could just slap the same glowing apple on their laptop lid, there would be less incentive for people to get original Apple laptops. Same here.
Honestly, if you can get away with it Kanban + NoEstimates + Continual Releases.

Scrum becomes useful when you are required to plan(or attempt to) schedules for certain features far in advance.
I don't think conspiracy theory is the right word for it. The world isn't ever that neat :)

His statement, when you refine it appropriately (which is not always done in an online forum), only presupposes that most people of the field who are visible to the public are "either idiots, fanatics or crooks".

I wouldn't phrase it quite so strongly (and for what it's worth, the grandparent didn't either), but it's easy to see why that would happen. Since economics is mostly about money, even slightly bending the public's perception on what scientific economic consensus is can have an extreme payoff via influencing public policy. So a lot of money is spent on trying to do so (virtually all of the so-called "think tanks"), much more and on a much more consistent basis than in any other science. So even from first principles, without any evidence, you have to logically expect economics to be worse than other sciences at delivering a rational truth.

As for evidence, I wonder what you would even accept as a "non-ideological source"?

All that said, it's not like the economics profession is an entirely lost cause. There are people like Dean Baker and James Galbraith who manage to occasionally bring alternative voices to the public.
Git down uses Arduino to moderate commits based on alcohol level
Process Substition – The Best Kept Shell Secret
The benefit is to provide incentive for designers to create original products. Essentially in exchange for bearing the costs and risks of creating something original they are rewarded with a small monopoly.

But extending copyright to ridiculous terms like 70 years past creators' death does little to achieve that goal. Also, as the article points out, extending the terms retroactively is just egregious - you cannot incentivize anyone in the past.

I personally feel that copyright and patents are useful but the terms should be much shorter than they are now (and they have a tendency to become longer with time).
Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values."

I've never been on a team that does pure Scrum - even ones which intended to do so always ended up with what we termed "Scrum-ish": taking the ideas from the base methodology, but adding a whole level of 'house rules' aiming to patch up obvious gaps. For instance, always making time for one refactoring or technical debt task per sprint, tracking accuracy of estimated time versus actual time elapsed (deeply uncomfortable but very useful!), the hundreds of different rules around trying to make standups shorter and more useful.

I am a big fan of well-run retrospectives, though: they can be a really nice way to feel empowered as a developer, especially when you have one retrospective identifying that Thing A keeps causing everyone pain, and the next retrospective having everyone say 'Hey, Thing A is so much better now!' Never realized they weren't 'meant' to be about technical matters, though: in our Scrum-ish teams, they were always open for all topics, and I think that's a very good idea.

Of course, the fun thing about Scrum-ish teams is now you have a whole new level of debate that can happen: "We're failing because we're not doing Scrum rigorously enough!" vs "We're failing because we're doing Scrum too rigorously, and what we need is more house rules!" ;)
Direct addressing is the preferred configuration. Only if your existing code's working set does not fit in MCDRAM does the cache configuration make sense.

It might sound pedantic on my part, but 'it can act as cache' is very different in practice from 'It is a cache'.
For me it would have to be the Michael gerber's Emyth books. It will forever change how you think about business and maybe the world around you.

Followed by sam carpenter's work the system. I think if you're a programmer trying to make it as a business person those two books are the most invaluable.

Edit: about the how part.. Before reading and understanding these books I was always in a kind of firefighting mode. It was like a constant pain in the neck that something was somewhere needed me. Sure i was making money but I was not enjoying it and felt stressed all the time. Plus I wasn't scaling my business because of the constant need of attention from everything. Then I learned the systems thinking and it all started to change.. It was like I felt I had wasted 10 years of my life being stupid before. I'm telling you these two books can forever change your life both professionally and personally if you aren't already doing it.
MockupUI – New UI mockup and wireframing tool, built with Qt
Do the proper research, the nuclear option is much less promising as the proponents claim (again, "wishful thinking" not the facts). Again not under the assumption of zero growth that they use. Check the real numbers and the technologies known to actually work, and see how long the "growth" is physically possible. That's our subject: the possibility of continual growth.

And do watch the video.
> it would have been unimaginable for a member of the peasantry to even claim equality with some lord

Peasant wars, uprisings etc show that it wasn't unimaginable, just mostly not realistic.
> If you are serious about making your own programming language, I would strongly suggest to target the LLVM.

Strange advice given the state of LLVM on platforms such as windows. Both Swift and Crystal, LLVM based don't run on windows for instance. LLVM gives you more quickly but at the cost of portability.
It's not software or hardware this time: there's a crippling power outage at ATL, which is Delta's main hub (and presumably where their mainframe herd is based):

http://fox61.com/2016/08/08/delta-airline-reports-outage-eve...

The outage began at 0230 and is presumably ongoing and beyond the capacity of their backup generators to cope with.
Dormant Earth germs could spring to life in a Martian puddle
Today, money is immaterial. Your argument, as poignant as it may be, doesn't follow.
"the team size is too big" - this is a very good point. Towards the upper limit of the recommended Scrum team size (3-9) they can get really unwieldy. I've been to a standup with an even larger team, which included a couple of design and marketing folks, and it was unbearable. The recommendation's there for a good reason.
Well, yes, security updates can be important. However, since I run a home-built Android distribution on the thing I can keep it up to date with the most egregious bugs (SurfaceFlinger bug etc.). This leads to the odd situation where my oldish phone is more secure than my wife's much newer Xperia C3 running a stock 4.4.4 distribution.

..which reminds me I have some more work to do, given the recent publication of https://source.android.com/security/bulletin/2016-07-01.html
This is mentioned in the article as possible only for small changes. When the refactoring involves more systemic problems, it becomes impossible to make the change in the course of making other client-facing changes.

I'll add that some subsystems are a mess but stable. It's difficult to make refactorings with other changes when there aren't other changes to make. I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change.
Also, their name is already an analogy: pointer.
Best of luck getting your sis to quit :-)
Exactly. Apple could offer more RAM and innovation on the GPU side. And more ports.
LLVM works fine on Windows.
Arena Animation Dilsukhnagar- Best Animation College in Hyderabad
This talk about agile by one of the founders was posted on Hacker News a while back, it is good, and I think complements this post:

https://news.ycombinator.com/item?id=11548334

To summarise, the issue Dave Thomas has with agile is that it has become a prescriptive framework, 'Agile' (with a capital 'A'), rather than what it originally started out to be, which is a means of being agile (small 'a').

I really liked this talk, and agree with both him and the OP of this thread that some parts of the 'Scrum' as a prescriptive framework may not work for you.

I find it a bit strange that the OP singled out the retrospective as being a negative- for me this is the best part about 'Scrum', as long as you're not too prescriptive about it.

Really the retrospective is a chance to improve yourselves as team each sprint, and it's a chance for people to get stuff off their chests. It shouldn't be just about scrum, it can be anything - adopting new approaches to development eg: TDD, discussing the state of the code, anything. That's what makes them (for me anyway and I think(!) my teams) enjoyable & useful meetings.
These are just games designed to avoid some estimation biases. The problem with biases is that one still can be caught by them even if they're aware that they exist, so such games might have some value.

An alternative would be to explain what the biases are and address them in each estimation round. But who does that really?

We've settled on playing games, which can seem childish at times.
antlr's c++ backend is pretty good for complex projects
The guide was made because the founder of Michelin liked to travel and liked to eat. Over time it grew into an actual product. Rail is well established in Europe. You don't necessarily need a car to visit any of these places
Love the caption. Straight out of the future!
I agree with you: it is a long book, with more problems than can be enumerated and discussed here, but key amongst them is the idea that inequality--the Gini coefficient--matters above all else, and particularly matters more than the absolute improvements in living standards that we (most of us) have experienced in recent centuries. I don't think one's goal should be to enter the ranks of the 'fabulously wealthy'. Anyway, by definition, there will always be a bottom 10% or 20%.
Again, is it then also reasonable to dismiss palaeontology as having 0 "scientific content", since it can't use the scientific method either?

This is an honest question.

(And I am no economist, but afaik, the economists note that "homo economicus" is a simplification. Most every science use simplified models, especially in the first university courses.)
>The daily standup deserves a blog post of its own

I found this to be a really good article about standups: http://www.yegor256.com/2015/01/08/morning-standup-meetings....
All of the items you listed under unconsidered should be brought up by the dev team. If the dev team is uncomfortable bringing them up, then that's probably a sign of friction between the dev team and management, which is really common.
However most of these biases are slightly recursive.

it always takes 20% longer than expected, even when taking into account it takes 20% longer.
I don't think there is much to say here that hasn't already been said about IoT security - like many commentors mentioned before, we're going to be going through a very rough period for some time where IoT devices just aren't up to par with expected security procedures, and consumer awareness campaigns will be necessary to educate less savvy consumers about the potential dangers of IoT devices at the moment.

In particular, start ups trying to capitalized on IoT in niche products will need excess scrutiny in order to ensure they're not trying to run fly-by-night operations just to make a quick buck. Chinese IoT knock-offs will also need to be monitored carefully as well.

What's most frightening to me on something like this is even tech-savvy users are fairly screwed as your ability to interact with the device and try to remove or clear the ransomware manually will be restricted by the same methods meant to prevent you from tampering with the device in the first place. This likely can leave people without any recourse to ranson scenarios like the thermostat being hijacked, and the end-user will have no option except to remove the device.

Hopefully either a consumer or business alliance crops up with suggested practices for IoT devices, including remediation methods for these very scenarios. I think it's preposterous for companies to assume that their devices will never be compromised, and if they're going to lock down the devices, they need to provide a guaranteed way to reset the device; a bit of set up work certainly beats paying to make sure your fridge still works tomorrow. With IoT creeping out as the next "must include" feature for manufacturers, this sort of consumer protection is going to be essential.
> It's really very simple. If the evidence is not ignored, it's an incentive for illegal searches.

I know that's the theory, but most countries don't have this and they also don't have plague of illegal searches, because, you know, they are illegal and police tends to do legal things and they can loose their jobs and be prosecuted if they start doing illegal things.

I understand that the police in USA has a history of allowing police to do illegal things for "greater good" but ignoring evidence is way too late to prevent illegal searches.

> You could not be more wrong on that point.

In USA, maybe UK and perhaps few other countries I'd be. In virtually any other country I wouldn't be.
Did you just compare a project management methodology with theoretical physics? Sounds to me like you try to compare apple with orange. Sorry, I don't follow you.
>Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO.

Pretty much every kind of deadline driven development ramps up technical debt. Scrum certainly isn't the worst in this respect (developers make their own deadlines, and conscientious ones will build the time in), but the emphasis on commitment and the pressure to deliver at the end of the sprint puts pressure on developers to cut corners.

The worst part though, is that the product owner is usually non-technical and will deprioritize stories to clean up technical debt as a result.

IMO for any kind of development methodology to work it must have an opinion on technical debt. Scrum doesn't.
You may also enjoy the U.S. equivalent to the Ordnance Survey, the USGS. https://www.usgs.gov/
His complaint about the standups interrupting productive work rings a bell with me though. I see no reason why a daily status update over the general channel on slack doesn't serve the same purpose as a standup meeting. In fact, make it so there's a loose timeframe, say 30 minutes, and you wouldn't be interrupting people, nor forcing them to stare at a wall.

My team hasn't tried anything like that, but I think it could really be useful. It encourages better communication throughout the day as well, as it gets people using Slack. Plus, it gives managers the ability to keep track of what people say each day.
Yes, thank you. The attitude of 'you may not describe a problem without already having prepared specific, actionable solutions to it' is limiting and only really appropriate in situations where time comes at a very high premium generally, i.e. meetings and such, or the value of actually solving the problem is too low wrt time spent coming up with solutions.

In almost every other situation, writing articles on the internet included, simply describing perceived problems so that you and others may consider solutions to them immediately or at a later time is extremely valuable, and is a necessary (but insufficient) condition of progress being made.
[Rework][] from DHH and Jason Fried.

Rework explains the "life beyond work" and "make a dent in the universe" philosophy behind Basecamp and Rails and is a valuable counterpoint to the popular media narrative of the startup IPO mindset. The book also explains how to apply the philosophy with actionable examples and it's fun to read.

[Rework]: https://37signals.com/rework
> tracking accuracy of estimated time versus actual time elapsed (deeply uncomfortable but very useful!)

It should only be uncomfortable if the team means 'commitments' when they say 'estimates'.

This is part of the reason stories are generally pointed with (more or less) triangular numbers. So that teams stop fretting about missing estimates by an order of magnitude or less.
What's the societal purpose of design patents?

It does give more incentive to produce original designs, but it also means that a well thought-out design won't be immediately copied. At least not exactly.

Lets use chairs as an example. One can't really put a utility patent on a chair, as they are commonplace. Most chairs are pretty standard designs (subject to location).

But occasionally, you get a chair that is truly unique. It is both beautiful and functional, nearly artlike. Maybe the designer had to tweak it to get it comfortable. Maybe there are a lot of details, or you've figured out a detail or style that is unique to your production. The patent provides the designer (or company) with the exclusive rights to produce that art-like detailed chair. The competing company theoretically can't produce an exact replica.

Sure, there will be some cheaper places that have the same sort of feel, but like clothing knock-offs, something is generally missing (like quality) and details have been changed.
Money is immaterial?!? As Homer Simpson once said (to his brain): "money can be exchanged for goods and services" - like healthcare, education, important stuff....
I'm pretty sure that only a minority of rich people are really in the ideas and creation business. If you live in Silicon Valley it might appear different, but globally speaking, the rich tend to fall into the categories of (a) inherited wealth, (b) upper management, (c) non-hard-science knowledge worker types (finance and lawyers).

Yes, r > g is only an aspect for (a), but the Piketty argument also has to be understood as a warning bell. After all, wealth and the resulting political influence make it easier to ensure that mostly (a)-types ever get into (b)- and (c)-positions in the first place. (And the tendency for this has always existed and exists today, just look at the university system in most countries for evidence.)