Yagni - <AUTHOR> http://martinfowler.com/bliki/Yagni.html <comment><USER2> Something this article largely ignores is that often you want to build the support for the presumptive feature now because the act of implementing it affects architectural decisions. It came close to this by saying

> _it does not apply to effort to make the software easier to modify_

But there's a difference between making software easier to modify (where the same effort could be expended later to retrofit the software) versus making architectural decisions. Often times trying to implement something teaches you that your architecture isn't sufficient and you need to change it. If you can learn that while you're building the original architecture, then you've avoided a potential _huge_ amount of work later trying to retrofit it.

To use the example from the article, what if supporting piracy risks reveals that the fundamental design used for representing pricing decisions isn't sufficient to model the piracy risks, and the whole thing needs to be reimplemented? If you can learn this while implementing the pricing in the first place, then you haven't lost any time reimplementing. But if you defer the piracy risks by 4 months, and then discover that your pricing model needs to be re-done, now you need to throw away your previous work and start over, and now your 2-month feature is going to take 3 or 4 months instead.

<comment><USER3> As I get older, both as a person and as a dev, I have come to the same realization as you: that a lot of the time I end up building things that I don't need "right now", but which I have to at least plan at the architectural level, lest be it a nightmare later on.

And then it hit me.. THIS is one of the areas of software development where I don't think reading more articles, techniques "mantras" etc will help. Only more practice will help. It ends up boiling down to how much experience as a developer you have, making those particular decisions.

I.e. It's a craft, not a science.

So as you grow up as a developer you suddenly find that you start to have certain "intuition" as to why I should actually plan for something that I don't need, vs actually ignoring something (a real "yagni"), but you just can't explain it in terms of generalizations. You end up saying.. "well.. it just feels like I Should do this, because I have been burned in the past when I ignored this intuition"

And I don't think I'm alone in this train of thought.

<comment><USER4> This sounds like the journey from "realization of the cost of hacking" to its "cure", the grand solution.

I had the same epiphany in my 14th year of software development when I realized that programmers Must Be Given Solid Platforms of Well Architected Object Oriented Code or they will Make A Mess.

However, now in my 34th year, my view is more "Plans are useless, but planning is indispensable".

I have "grand" architectures, but my architectures and their implementations are designed with the assumption that they will be wrong in a week's time.

And my advice to anyone reading this is YAGNI. More practice helps. But practice the right thing.

I.e. its war, not craft.

<comment><USER3> This is actually very interesting.

However, I still am left with the feeling that you have reached this conclusion by means of more than three decades of practicing both the right thing and the wrong thing as well (we all make mistakes, etc).

So basically, how did you realized that "Plans are useless, but planning is indispensable" if not precisely by trying to plan, and then observing it's uselessness?

I could almost bet that you now assume that the architecture will be wrong in a week's time and yet you always find a way to actually make it resilient to this and make it work, otherwise I would have to wonder how did you ever accomplished something if indeed 100% of your architectures was wrong in a week's time.

I.e., this is your experience in your craft. Flowing like water, Bruce Lee would say.

Now, the point I did not get though, is, what exactly are the differences between being a craft or being war?

If it's a craft I kind of assume, like you, that I'll never be able to design the perfect architecture, but only the best architecture that I could have produced at the time. And just strive to get better every time.

If it's war, then it basically means that at any time anything can explode, but then I would be filled with despair all the time I guess. Maybe not. Is this what you refer to? if it's war you have to design assuming it will break very shortly and then work around that? or "make do with what I have" as they say?

Again, very interesting points and I appreciate the discussion since this has been haunting me almost my entire career.

Edit: By the way, I hope you don't me if I quote you. Those are some nifty points right there.

<comment><USER4> I have done my fair share of over-engineering. =) Its not over-engineering if you need it, but turns out, most of the time, you aint gonna.

A team that just hacks and does YAGNI by accident, or a team that does YAGNI but doesn't plan, they often have a choice of how to build the feature right now. With a little bit of planning, we can see past the first few meters and choose the first step to be in the direction of the bigger plan. Without planning, the first step might be in the wrong direction. The hard part for my teams is to plan, and then still only _implement_ the first step. They're getting better =)

Its war because if you're doing something worthwhile, there's someone else trying to get your customers. I'm not suggesting your stuff should break. The opposite. Combine YAGNI with TDD and push working, tested features to production ASAP.

<comment><USER5> _With a little bit of planning, we can see past the first few meters and choose the first step to be in the direction of the bigger plan._

I had a suspicion that despite the black-and-white way you have expressed your opinion elsewhere, particularly in your exchange with eridius, there probably was actually some common ground here. I don't believe it's possible to avoid the failure modes eridius describes without thinking ahead to some extent; this passage suggests you actually agree.

I can't speak to your experience with your team, but I can say that I've spent a lot of time fixing or working around other people's poorly-considered design decisions. In many cases I understand there wasn't time to do it better; the product had to be shipped. But in some cases I think a little reflection would have shown a better way which wouldn't have taken any longer to implement.

</comment></comment></comment></comment></comment></comment><comment><USER6> I dealt with this recently. We wrote a system that had a hard-coded data size in it. Later, that data size had to change to a flexible value chosen on the fly, and I was the one that had to go through all the code to make all the changes so we could handle that. It took a long time. Partly because we had no unit tests (a whole 'nother discussion), partly because I wasn't familiar with the area (all the areas) of the code that needed to change, and partly because we had said, "YAGNI" and not made our code configurable enough from the get go.

I started to curse YAGNI in the middle of that chore, but then I paused and thought about the many months of productive use of this code that we had been enjoying before this point. And even though it took me significant time to make that change, the production code was still running along just fine during all that time, still bringing us value. I decided that I was glad we had said, "YAGNI" at the start.

<comment><USER7> It sounds like most of your pain came from the code not being DRY. That is, this data size constant was duplicated in many places, rather than defined in one central place.

Unless I'm misreading you, that's not an appropriate YAGNI case, as Fowler writes:

"Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify"

<comment><USER8> _" Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify"_

That's a very convenient distinction. It lets you No True Scotsman anyone who challenges your position, yet provides little if any practical guidance about the best thing to do in the real world.

<comment><USER7> That might be a way to "win" internet debates. But I use it to write software.

It's actually quite simple. YAGNI applies to features/functionality only. Not refactorings.

<comment><USER8> That is an argument for refactoring only immediately prior to implementing a new feature in order to support development of that feature. In itself that is reasonable enough, but it becomes less effective as a strategy if the cost of just-in-time refactoring prior to implementing each new feature turns out to be significantly higher than the cost of setting up the same design at an earlier stage.

<comment><USER7> When to refactor/clean up code is an interesting topic. My rule is to only refactor old code when the bad design gets in my way. If we have some bad code that just keeps working, there is not much reason to clean it up.

New code I try hard to factor into tip top shape.

This is entirely separate from YAGNI in my dictionary.

<comment><USER8> That all sounds perfectly reasonable, but please answer me this: how do you decide what "tip top shape" is for your new code?

If YAGNI is an argument for not making any sort of advance judgement about future requirements until it's clearly necessary, then it is necessarily also an argument that as soon as any code meets its immediate requirements you should stop working on it and move on to the next sure requirement, without wasting any time on refactoring that might never prove useful for future development.

I suspect that many here who would say they agree with YAGNI do in fact edit their code beyond just working no matter how much it looks like spaghetti, in which case I would argue that the difference between our positions is merely a matter of degree, not a difference in the underlying principle.

<comment><USER7> Yeah, some/many people forget about the Ruthless Refactoring part of XP. Or they're just not good at it. Like how some decide to not write documentation and declare themselves "agile".

The successful XP teams I've been on probably spent 1/4 of their time refactoring. Once your code works, you clean it up, and refactor anything it touched. THIS IS THE DESIGN PHASE! Without it, you're just another pasta merchant. What truly blew my mind was that designing/architecting the code _after_ you write it is so much easier and effective.

> If YAGNI is an argument for not making any sort of advance judgement about > future requirements until it's clearly necessary, then it is necessarily > also an argument that as soon as any code meets its immediate requirements > you should stop working on it

That is not the YAGNI I know. It applies to external requirements only. Keeping your code base well designed, readable and bug free is an entirely separate concern.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> In my years of experience (both in big corporate R&D as well as startups) I've _never_ seen a project fail because of the end product being too simple or not having enough features.

However on the other hand I've seen _countless_ projects suffering delays, staff departures, emotional team arguments and eventually bad end product because of too complicated software architecture that overwhelmed its creators and because of obscure features that well-meaning engineers built in because "it'll save time in the long run".

Btw this well known XKCD sums it up just perfectly: [http://xkcd.com/974/](http://xkcd.com/974/)

</comment><comment><USER10> As always, it's a joy to read Martin Fowler.

It's so, so hard to resist the siren song of premature optimization, though. It's even harder in a corporate environment where "Well, why didn't you plan for that?" is a question lurking behind every failure or delay. Overplanning isn't punished.

<comment><USER11> I disagree. If overbuilding or over planning is wrong. Then the question comes as to why you spent $200k building a feature that just got thrown out. Or worse, they try to use a unneeded feature just to justify the fact that it was built.

<comment><USER10> I didn't say it isn't wrong. I said it isn't _punished_. That's a very, very different thing.

Enterprise environments encourage toxic behavior in numerous ways. This is one of them. Risk aversion is generally more important than cost control in the enterprise. Conway's Law in action, if you think about it.

</comment></comment></comment><comment><USER12> These days, I think "Yagni" is often used as an excuse for sloppy code and as a justification to avoid thinking about design.

I think the principle as Fowler describes it is valuable, but it can be easily abused. Taking the application of "Yagni" at the microlevel to its logical conclusion can be used to justify a mindless, just move on it and fix it later style of coding into which good architecture cannot be retrofit.

<comment><USER13> I have yet to see up-front "architecture" add value, and I have seen it sink a company.

<comment><USER12> Hi lmm, perhaps the world "architecture" has bad associations for you that I don't intend to imply. If you code anything non-trivial, you are doing architecture whether you like it or not. The only question is how well you do it.

Over-engineering is a real danger, to be sure, and terrible ideas can by justified in the name of "architecture," just as they can in the name of YAGNI.

Fwiw, I have personally seen costly decisions made in the name of YAGNI, literally. So I don't think it is the essentially "safer" default.

My view is that you can't always wish away complexity with heuristics. Often, you have to think through your special situation, weigh the factors, and make tough judgment calls without knowing if they'll be right.

<comment><USER13> I'd be interested to hear the specifics, or examples of the kind of "architectural decision" you're talking about. Let me tell my story of how architecture went wrong:

* We defined the data structures early on in a generic way, when we thought we were building a product for multiple regions. In fact we tried two regions and discovered it only sold in one of them, so we were producing a product that only actually needed to support a single region, with a massively overengineered generic data structure

* We defined component boundaries, saying that certain functions would live in certain modules. In fact these were not the correct boundaries, and simple operations involve several rounds of back and forth, exacerbated by:

* We built a "SOA" style system with multiple components on the grounds that we would need horizontal scalability. We never got to the level where we needed that kind of scale, and the architecture massively slowed down development/debugging.

* We decided that certain interfaces would use Java datatypes because we thought the system would primarily be written in Java. As we built the system it became clear that Scala was a better choice for many components, so we ended up with a lot of code that was converting scala objects to java just to send them through an interface, and then the system on the other side was converting them back to scala objects.

* We tried to make a choice of RPC system early on. We ultimately went through three iterations of different RPC systems, as the various approaches failed.

You could say these are just wrong choices, and there's an element of this. But I think in all of these cases we'd have made the correct decision had we been driven by use cases (YAGNI style) and deferred making decisions until we actually needed them.

</comment></comment></comment></comment><comment><USER14> We have one rule when planning product features: Everyone may shout YAGNI at every time. Saved us so much time and complexity, it's incredible.

On the other hand, I have a love/hate relationship with YAGNI, as it requires careful weighing - additional features that need to be reflected in architectural changes which would not only take refactoring code but API and data model changes as well, possibly with data migrations, coordinated across multiple teams are a completely different picture. The costs of building it now may be an order of magnitude cheaper than doing it later. Further down the road, startup mechanics and traction apply as well. If you have an order of magnitude more resources to fix YAGNI later, it might be worth the additional speed right now. I feel that putting all of these into context and doing something that makes sense is just freaking hard every single time.

</comment><comment><USER15> Except that Fowler used YAGNI to produce the "Chrysler Comprehensive Compensation System" that _FAILED MISERABLY_. I still don't understand why people continue to listen to him--he has yet to demonstrate a large project he was in charge of that succeeded.

YAGNI gets you the easy 80%. The problem is that YAGNI means you didn't _prepare_ for the hard 20%, and now you're going to get killed.

Of course, YAGNI is really good if you're an ambitious manager since you'll be gone when the 20% comes home to roost.

<comment><USER13> Most C3-like projects fail after a decade and millions of wasted dollars. Failing faster and cheaper provides real value.

<comment><USER15> Except that there was already a working system. So, the C3 system was _totally_ wasted money, and never achieved any significant subset of functionality of the old system.

A "proper" use of agile would have been to gradually convert chunks of the legacy system to a unit-tested system. Use bug reports and feature requests to prioritize the chunks which need to be tested. Once that happened, you could begin evolving the old system and adding features without worrying about breaking it.

But _that_ wouldn't get noticed. Much better to have a _BIG, NOTICEABLE_ failure that you blame others for than a less noticed success. That's how you get promoted, don'tcha know.

See: [https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)

</comment></comment></comment><comment><USER16> I think this is trying to simplify an already simple idea, succinctly: "Optimize your time intelligently".

Rules of thumb (like YAGNI) may not be correct, depending on the situation. Estimating time complexity is hard, so deferring development defers mistakes in estimation. Great.

However, if you know that you have a 90% chance of needing a feature in 6 months, and it will be 2x easier to build now when you have a team actively engaged on a similar project, then YAGNI is the wrong choice. Counter examples exist, like you are in such an extreme environment where (like first month of a startup) the opportunity cost of those programmers is very high.

Regardless, I would ask "Is this the best use of time now" rather than "YAGNI".

<comment><USER17> The whole point of the article is that you're wrong. And I tend to agree. Not trying to predict feature needs down the road is extremely empowering. Building you're unnecessary feature now is just as likely to increase the complexity of everything in the future as it is to be 2x easier to build now. YAGNI dramatically simplifies the answering of your question: if it's not needed now, don't do it.

<comment><USER16> Using your example: Let's say I know it will cause a complexity burden in the future. Shouldn't we ask if that complexity burden and opportunity cost are outweighed by the expected benefits, rather than rather than simply relying on a simplistic rule of thumb of always deferring?

People are capable of (which, to your point is not the same as being consistently good at) making good calculations as to what is a waste of time.

<comment><USER17> Quite a contrived scenario, but, no. Just build the feature you need and move on. No need over-analyzing.

See? I didn't have to get trapped in your pretty much un-answerable pondering.

Following the rule crystallizes a lot of decision-making. It's very empowering when you don't have too many objectors.

<comment><USER16> And yet, you might take longer to finish the project than someone else. Just because something is freeing doesn't mean it's a good idea. Nor does it mean it is a bad idea, it just means it's an uninformed idea.

Obviously it's suboptimal to ponder an un-answerable question. That doesn't mean it you shouldn't spend 1 minute thinking about it.

</comment></comment></comment></comment></comment><comment><USER18> I think it is important to differentiate between "early building" of features you don't yet need, and building in a way that doesn't require much refactoring in order to extend/add those features on.

More common than overbuilding features is overbuilding function or library capability. The right balance, IMHO, is _thinking_ about the extendability & designing for it but leaving out the actual details. This tends to lead toward good, SOLID designs that are easy to work with later rather than a blind-ally you need to spaghetti-mofongorate to get to work.

"Refactor later" is fine for folks like Martin Fowler who know _how_, and who haven't painted themselves into a corner with bad early decisions. It is a bit dodgy to tell the average mid-level dev who just wants to "get it done" so his Project Manager can check off their Excel spreadsheet that they are on time.

<comment><USER19> Extensibility is itself a feature, so YAGNI would imply it shouldn't be assumed until proven necessary.

I personally use the "zero, one, many" rule (i.e. those are the only counts of things, there is no such thing as 2 or 3, etc.) as my proof of necessity. If I ever get to the point that I need two of something, I make it useful for many of something.

<comment><USER10> I've found that designing for extensibility is wrong more often than right. The code doesn't stretch the way you expect, and then it strains against other boundaries you didn't realize you were setting.

<comment><USER18> that's not quite what I mean.

saying, "I think it will need feature X, which will require parameter x_id, so I'll add x_id = 0 now" is wrong.

writing (just as an example) a function that takes an config array as its param so you can later build out, instead of passing a_id, b_id, c_id...."oh, crap, how long a list will this be?" in the early build is the type of thing I mean.

Writing extensible code more often than not causes you to write smaller, tighter, more testable components. Writing in this style is what I'm trying to say. Many less experienced devs would not do this and end up with long procedural code because they feel it is wasted time for something they aren't anticipating.

</comment></comment></comment></comment><comment><USER20> I'm always a bit surprised when we treat "cost" as something binary.

Successful people, in my experience, are those who take calculated risks and are right often enough to differentiate themselves. Software is no different.

When faced with a YAGNI situation, you need to make a judgement call. There will be costs in building it now. Those costs might be less now vs later (sometimes just because the context is fresh). The cost may vary depending on how much work you do.

There will also be "expected benefits". The estimated (judgement call) likelihood of actually needing it times the cost savings (future cost - current cost). Compare the expected benefits between projects and pick the one you expect to add the most value.

As pointed out by others, this often means simply drawing the abstraction in the right spot to make future development easier. Even if future development never happens, it's likely you built a good abstraction that was well thought out. The cost is low (you had to frame the abstraction somewhere) and the expected benefits are high.

</comment><comment><USER21> _Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify._

And here is where the _actual_ frontlines of the battle are fought--because it's needlessly verbose and abstract architectures (or what people think are them, anyways) that are railed against by folks chanting "yagni yagni yagni".

This article neatly sidesteps the actual thorny issue of "well, when is designing extra actual a good idea?" by ignoring one of the biggest use-cases of yagni.

<comment><USER22> I hear you, I think this article is really good for someone who isn't familiar with the term YAGNI. However as the above poster mentioned it sidesteps a big issue which is when YAGNI is wrong.

Generally I feel like YAGNI is appropriate for features but not appropriate for architecture. I feel like the purpose of architecture is to try to plan ahead, or to make the determination how far ahead one is attempting to plan. Its perfectly find to architecturally choose not to support something, but it should be a conscious decision.

<comment><USER23> If I may extend your metaphor, the problem then becomes the scaffolding that lies between architecture and features. Another attempt at a rule of thumb is to ask the question: can I describe how this likely-but-not-yet-needed change would be addressed in the code? If there's no answer (or the answer is not satisfactory), the question becomes: what do I need to do to have a good answer to the previous question? And so on.

</comment></comment></comment><comment><USER24> I think the ability to use YAGNI scales with the experience and abilities of the developer and the team. I have walked into wonderful lean codebases where an experienced hand has kept featuritus down to a minimum, but I have also walked into codebases where multiple kitchen sinks were not only present and plumbed in, but a pile of new ones were ready and waiting by the side to join them, and it was a massive distraction.

</comment><comment><USER25> These comments seem to illustrate something I have felt for a while: yagni is incredibly divisive topic and for every person saying praising it is another who is at the very least cautious of its application.

It makes me wonder where the divide is.

Perhaps more large 'enterprise' shops where projects can spin out of control into what they 'must have' whereas the small shops where you need to get a product out ASAP?

Or maybe age of developer, with the young eager guy confident he can whip out all n features in 3 weeks so we might as well add that feature too vs the experienced dev who knows better and we will add it once it is needed?

I have put some time and effort into asking people about this very question, but still am no closer to understanding why some really appreciate it and others hate the phrase.

Personally, my guiding principle after being bit by yagni is that it is a wonderful principle to use when making _product /feature_ decisions but should be exercised very carefully when making architecture decisions. Which makes sense, features come on and go, but architecture is generally something you need to live with. In other words, whenever yagni is used is an argument against what are more good coding and design practices than practical problems, then it may be something more of a case of 'no really, we are going to need it'

<comment><USER26> Funny, I think of the age divide running the other way. Younger devs, who came up during the age of agile, take YAGNI as a given, while older devs have seen the results of too many hasty decisions.

The advice I was given when I started out was, "it's cheaper to fix something upstream". Catching a potential problem during design is always cheaper than catching it during development, which is cheaper again than catching it after release.

This argument always seems to get lost in the YAGNI discussion.

</comment></comment><comment><USER27> The use case in these discussions is never about framework or shared code.

Taking the example of the lookup tables for error messages, imagine if you shipped your framework and lots of teams started using it, then you iterate to change your APIs in a breaking way and suddenly the cost of that change is multiplied by all the teams refactoring.

It is also worth considering the cost of changing existing production code, this is typically where most bugs are introduced, especially when someone else is implementing the fix without the domain knowledge of the original author. Unit tests won't help if they also have to be re-written to match the new API, as they are by definition new/different tests.

I think writing malleable code is the key takeaway from this article, and if thinking about future possibilities helps with this, then it should be encouraged.

Being unable to predict the future doesn't mean you shouldn't anticipate and prepare for change.

</comment><comment><USER28> There's an extensive literature on _opportunity costs_ in economics, but you wouldn't know it from reading this article, even though that's basically what it's about. Discussions of programming methodology often seem to involve reinvention of the wheel. Has there been any work done to quantify these theories?

</comment><comment><USER4> I used to play Age of Empires. Its a real time strategy game where a common match is for two teams of three to try to kill each other. A feature of the game is that each player can spend resources (gold, wood, etc) to reach new "ages". Players start in the stone age, and advance to tool, bronze and iron ages. Each new age offers better weapons, better technology, greater efficiency.

Consider two games. In the first game, we observe that the players take on average 30 minutes to get to tool age, and only one player ever makes it to iron age before a team is victorious after about two hours.

In a second game, we observe that the players average ten minutes to _bronze_ age and all but one player makes it to iron age before the game is won after about an hour. All players invest in technology before fighting.

Who are the better players?

<comment><USER29> I can only assume that the point you're trying to make is that there's not nearly enough information for a reasonable answer. It's certainly hard to come up with solid ideas without a clear understanding of the game's pacing.

In RTS games, teching and building armies compete for resources, so I'd hazard guessing that Game 1 happens because somebody opted for early aggression, which forces everybody to spend money on units to fight off the early threat. Looks like a well balanced game where both teams kept the aggression level high, which justifies the long duration, and the low-tech end-game.

Second game looks like there was little to no early-game aggression, which meant that everybody got to funnel resources into teching up early. I'm not sure if late-tech battles are more all-or-nothing, or whether one team was just clearly stronger than the other -- though if that's the case, why didn't they push for an advantage earlier? AoE is much more symmetrical than, say, Starcraft IIRC, so one team having a weaker early game but a stronger late game doesn't seem likely.

I'm curious, though: how does this relate to the article?

<comment><USER4> Thank you for biting =)

The players in the first game are likely experts and if a team from the first game plays against a team from the second, the game will be over in less than ten minutes. Its not merely that "someone opted for early aggression", its that when playing at the elite level _all_ players opt for aggression. Its not rock, paper, scissors. Its a game of rock, paper.

The point is that deployed features trump undeployed "it'll be great when its ready" technology.

I'm happy for my competitors to opt for spending money attempting to achieve "good architecture" over "working code".

Ok, so the analogy is kind of shitty. Unlike Age of Empires, spending money on "good architecture" is actually less effective at creating good architecture than writing working code.

</comment></comment></comment><comment><USER30> Other than the navy wiping out all the pirates, I foresee a couple of other unforeseen scenarios:

1\. Within the next few months, a new risk emerges with higher priority than piracy. Implementing this feature will delay the piracy addition, but only by 1 month because much of the basic "support multiple risks" problem will be solved by this other feature.

2\. Within the next few months, a new product or tool will become available/known that makes it trivial to support storms, piracy, and a dozen other risks, making this whole effort redundant. It may be impossible to migrate to the superior alternative if all the resources are already tied up in a half-finished project that has generated no benefits to date.

</comment><comment><USER17> I love how these types of articles always bring out the architecture astronauts with all their pronouncements of "it depends" and whatnot. How hard is it to understand the notion of "building what you need, and not what you don't"?

<comment><USER31> > How hard is it to understand the notion of "building what you need, and not > what you don't"?

Very hard, because it's in fact a tradeoff. Let's say you are building a house. Will you have wife and kids in the future? YAGNI says you can always expand your house once you have kids. But do people really build houses that way?

To take more extreme example, first thing you expect from housing is a protection from elements. So according to YAGNI, you should build the roof first, and see if it's good enough for you (and you don't bother, for instance, that you can only stand in the middle of the room). Again, no one really does that with real houses.

The whole art of engineering is to pick the reasonable tradeoffs, and this includes hedging against the risk of future expansion. That's why simple pronouncements as YAGNI are not of much help.

<comment><USER17> Extreme examples are not that interesting (to me) since it's far more important to optimize what is not extreme.

A better house example is to go ahead and build the 2-4 BR house (like pretty much everyone does) but wait on the pool and jungle gym.

<comment><USER31> The extreme examples are just to illustrate the tradeoff.

Some architectural decisions have to be made in advance, because they are hard to take back. In your example, size of the property (if any) on which your house is standing is such a decision. Good luck building a pool in a 4-bedroom apartment.

(Interestingly, you said, "like pretty much everyone does" \- isn't that actually a sounder advice than YAGNI?)

<comment><USER17> I don't put much stock in extreme examples. Much more useful to review common examples.</comment></comment></comment></comment></comment>


One man's DIY fibre Internet service connects Marin County hamlet - <AUTHOR> http://www.sfchronicle.com/business/amp/One-man-s-DIY-Internet-service-connects-12175313.php <comment><USER2> Good job. Unfortunately efforts like these are contingent on being in a location where you have reasonable access to wholesale bandwidth and enough population density to defray the costs of buying bandwidth and building the network.

</comment><comment><USER3> Marin county is very, very hilly. Somewhere between hilly and mountainous, given that Mt Tamalpais sits smack in the middle of it. While most of the population is close to the freeway on the inland side, there are many many lightly populated areas with awful or no cell reception and issues with high- bandwidth type connections of various sorts. Many of the ocean-side areas are largely cut off from the main population by the mountains. I've never been to Dillon Beach, but it doesn't surprise me at all that Marin is where something like this would happen!

</comment><comment><USER4> What are the logistics of laying fiber yourself? How do you legally dig up the ground and put the fiber down?

<comment><USER5> He didn't lay it himself; he found that AT&T had nearby fiber and paid them to run it to his garage. Then he connects to his customers via antenna.

"Kuykendall now buys Internet service at a bulk rate from AT&T, then beams the connection wirelessly to other homes. Some customers get service free in exchange for hosting Mimosa equipment that relays the signal around corners and over hills to reach more homes."</comment></comment>


The ephemeral nature of software - what will you show your grandchildren? - <AUTHOR> http://successfulsoftware.net/2013/03/24/ephemeral/ <comment><USER2> I thought about this topic in the last two years manly (maybe because i am a dad of a 2 years daughter?). Since already a lot of "cool" work i did in the past no longer is showable, or i even lost backups (DOS games, simulations, 3D games, startup failures, web frameworks) i guess that the same would apply to the current projects. My conclusion was: as programmers we, at least, have to play the Museum Keeper role and consolidate our deliverables with proper VMs to show our software to our grandchildren. Let's all hope VMWare stays solid and VirtualBox never dies! :)</comment>


Are the Navy UFOs "Real," or Just in the Low Information Zone? - <AUTHOR> https://www.metabunk.org/threads/are-the-navy-ufos-real-or-just-in-the-low-information-zone.10921/ <comment><USER2> But the airspace of a US carrier strike group shouldn't really be a "low information zone".

</comment><comment><USER3> Electronic artifacts.

When several naked eyes and several radars can agree on a single object, maybe then I might be willing to accept that there may be a physical object there. Otherwise, no.</comment>


Harder than it looks: rounding a float to the nearest integer - <AUTHOR> http://blog.frama-c.com/index.php?post/2013/05/02/nearbyintf1 <comment><USER2> Floats are outrageously complicated. Tread carefully! If you ever deal with the nitty gritty of floating point numbers you should read every post on the topic on Bruce Dawson's blog. It's up to 15 posts long.

TLDR - if you think you know all there is to know about floats then you're wrong. Read on!

[http://randomascii.wordpress.com/2013/02/07/float- precision-...](http://randomascii.wordpress.com/2013/02/07/float-precision- revisited-nine-digit-float-portability/) (has links to all posts in series)

<comment><USER3> Thanks for the link. I think floats are pretty overused, I don't see fixed precision decimals getting used, which always struck me as odd.

<comment><USER4> I'd love to see a language or even a library that would make no-surprise fixed point and/or arbitrary precision math first class citizens, like what Python did with integers.

<comment><USER5> COBOL and RPG, for example, on Mainframe / Midrange systems have native support for fixed point (decimal) types. It's the second most used type, besides the "character" types. Floats are seldom used in the context of business applications. Fixed point math is even directly implemented in hardware on Power processors. Always been like that on IBM platforms.

</comment></comment></comment></comment><comment><USER6> I wrote a very similar article about how testing for integer overflow is also harder than it looks: [http://blog.reverberate.org/2012/12/testing-for- integer-over...](http://blog.reverberate.org/2012/12/testing-for-integer- overflow-in-c-and-c.html)

<comment><USER7> Well written article.

One of the things I found amazing about learning assembly was that in x86 asm it is relatively trivial to check for overflow (after an operation has happened) by checking if the overflow flag [1] is set.

Although this doesn't help with detecting if overflow will occur from an operation, it can be used to detect when it has occurred and assist recovery.

[1] <http://en.wikipedia.org/wiki/Overflow_flag>

<comment><USER6> Thanks! Yes I am also impressed by how relatively easy this is to implement at the machine level. One thing I meant to do for that article but didn't get to is implement each of those algorithms in assembly directly and see if the C/C++ solution would compile into the optimal machine code (or something equally efficient).

In assembly you have the luxury of no undefined or implementation-defined behavior. This makes things a lot easier, since you can count on things like two's complement. In assembly these checks are probably as easy as (untested):

        will_u64_overflow_u32:
          ; If any of the high 32 bits are set.
          shr   rdi, 32
          setne al
          ret

        will_u64_overflow_i32:
          ; If any of the high 33 bits are set.
          shr   rdi, 33
          setne al
          ret

        will_i64_overflow_i32
          ; If the high 32 bits are other than all 0 or all 1.
          shr   rdi, 32
          add   edi, 1
          cmp   edi, 1
          seta  al
          ret

I'm not sure if these are exactly right, but I think the right answers are about this simple. Any of these could also be written simply in C/C++ also, the main difference is just that in assembly you can make machine-specific assumptions (like two's complement) since you're already doing something machine-specific.

<comment><USER8> The shift in the second one should be 31, if I understand what you're doing correctly.

The third one is incorrect. Consider, for example, the integer 0xFFFFFFFF00000001, which is -4294967295 in 2's complement. It passes your test, but is not representable as a 32-bit signed integer. An alternative might be:

        movsxd rax, edi ; signextend(rdi mod 2^32) == rdi
        cmp rax, rdi
        setz al
        ret

<comment><USER6> Brilliant, I love it. Thanks for the corrections.

</comment></comment></comment></comment></comment><comment><USER9> Wouldn't this be easier if both numbers were just represented bitwise, and the float were converted to integer that way? Seems more straightforward to me.

Floating point representation works by having "exponent" bits, and "mantissa" or fraction bits. Also a sign bit. For explanation's sake let's say we have a single precision 32-bit FPU. IEEE 754 single precision is 1 sign bit, 8 exponent bits, and 23 mantissa bits. The exponent bits are subtracted by 127 to yield the exponent.

So, the basic formula is:

      (-1)*sign * 2^exponent-127 * 1.mantissa

So right away, if exponent < 0x7F, round to 0.

If exponent > 9E (for 32-bit int), round to infinity.

Multiply

      1.mantissa * 2^exponent-127

This will be a power of 2 so there's probably a fast bit-shifting method for this. I'm just too lazy to look up how this should be done.

If exponent > 0x96, the exponent's too big to represent fractions of 1, so you're done.

Otherwise, you're within 1 number. If the remaining decimal < 0.5, truncate. Otherwise, add 1 and truncate.

<comment><AUTHOR> You can definitely round a float to the nearest integer-represented-as-a-float by accessing its bits. It will work.

It will not be faster on a modern processor, though, because floating-point numbers live in their own registers, distinct from integer registers. Floating-point registers do not have bitwise operations, moving data to and from integer registers is comparatively expensive, but they have IEEE 754 arithmetic.

So the game is to do as much as possible with what instructions there are. One such instruction is for instance (for processors with SSE2) " cvttss2si %xmm0, %eax", to truncate a float in xmm0 to an int in eax. Intel provided an instruction for that because the C language defines the cast float -> int as a truncation.

The next blog post in the series will be about using IEEE 754 addition to avoid the round-trip through eax altogether.

<comment><USER8> SSE4 added FRNDINT (x87) and ROUNDSS/SD (xmm) to do this task purely on hardware.

Further, if one is seriously determined, there are ways to perform bitwise on floating-point registers directly. On XMM, it's trivial: just take advantage of the integer (and non-integer, e.g. XORAPS) instruction available.

On x87, one can take advantage of the direct mapping between MMX and x87 registers to manipulate them using MMX's integer instructions. This has problems, but as I said -- seriously determined.

<comment><USER10> On modern x86 hardware, integer instructions that act on float values in xmm registers (and vice versa) require a somewhat expensive change of execution domain. That the register names are the same is irrelevant: everything will be renamed into what the CPU works with internally (which is separate integer and floating point domains).

Mixing integer mmx and x87 is even worse, with the crazy emms junk. Not worth it.

<comment><USER11> The penalty is at most ~1 cycle of latency -- in practice I find it gets completely absorbed by the OOE engine. I've never measured any significant penalty in any code for mixing float and int SSE operations on any x86 microarchitecture.

Floating point bitwise operations exist too: xorps, andps, and so on.

<comment><USER10> Hmm, ok. Intel recommend avoiding it pretty strongly: I guess they overstate their case. One cycle in (and one out?) isn't exactly crushing.

</comment></comment></comment></comment></comment></comment><comment><USER12> The title piqued my interest in how to implement rounding of floats, on the bit-fiddling level - certainly not an easy task! Disappointingly though, the article starts out by using type casting. If it's a solution on that level we're after, why not just use roundf()?

<comment><AUTHOR> If you feel that using type casting to implement round-to-nearest-integer is cheating, an earlier post is on the subject of implementing a substitute for type casting without type casting.

It uses only floating-point arithmetic, but it should still satisfy your curiosity for bit-fiddling.

[http://blog.frama-c.com/index.php?post/2013/05/01/A-conversi...](http://blog.frama-c.com/index.php?post/2013/05/01/A-conversionless- conversion-function2)

</comment></comment><comment><USER13> Doesn't the modulus function avoid most of the issues, here?

        float RoundToNearestWholeNumber(float f) {
            if (double.IsNanOrInfinity(f)) return f;
            if (f < 0) return -RoundToNearestWholeNumber(-f);

            // make sure we're working with a consistent value
            float v = DiscardExtraPrecision(f);
            // the fractional part is guaranteed to be representable
            float r = v % 1;
            // largest whole value up to v (the floor)
            float w = v - r;
            // switch to the ceiling if in the upper half
            if (r > 0.5) return w + 1;
            return w;
        }

Feel free to disillusion me.

</comment><comment><USER14> Hi,

I don't understand the problem with a) rounding floats to integer and I don't understand b) why you would ever have to overflow an integers.

a) Wouldn't it solve the problem to write an algorithm that can use mathematical axioms like +,-,/,* virtually using strings? I mean you want it to calculate 99999999999999999999999999999999999999999999999999999 + 9999999999999999999999999999, why not teach it how we do this instead of having to use bit-hacking tricks? Maybe my example isn't good, but I mean writing an algorithm that reads 999 for example and 1000 knows that it now has to put a 1 infront of 999. You see, that's what I mean by manually.

b) And can you please explain "why" it isn't enough to use ie. a linked list of 8bit virtual address spaces and allocate using virtual address spaces everything that fits into RAM and everything that goes beyond the addressable space onto swap?

Why would you have to worry about flipping bits in an overflowed integer/float, when you could use that mechanism. Don't you just recursively run through the virtual address map until you're able modify the allocated data in that memory segments again? I don't see a problem with this implementation except for performance maybe.

When the algirhtms knows about the 32bit limit for example (constant), you can tell it to not allocate real memory with that size, but allocate virtual memory with that size dependant on the input data size. Yes I know that the CPU has built-in mechanism for the mathematical axioms, but doing it manually would solve the problem, from my limited perspective.

Sorry if I'm blind for seeing the problem, I'm not ignorant, just really curious in how this can be solved once and forever.

<comment><USER15> a) That solution is sometimes implanted. The problem is: its slow, very, very, slow. It is not nearly as fast as regular integer arithmetic. (Also, +, -, /, and * aren't called axioms.) Also, how do you handle things such as powers and exponentiation (especially non-integer arguments)?

b) Search up for "BigInt libraries". The problem is the same with the others, its slow. You still have to allocate memory and the operations aren't as fast. However, BigInt libraries are widely used when necessary.

<comment><USER14> @omra, why downvote a question? It wasn't a proposed solution to the problem, it was a question on if there is a solution similar to that and otherwise why this would be wrong. I have added that I believe that this would be slow, if you read it carefully.

Btw. "axiom" was probably an unlucky translation of "Körperaxiom". See: <http://de.wikipedia.org/wiki/K%C3%B6rper_%28Algebra%29> The english wikipedia says:

"The most common way to formalize this is by defining a field as a set together with two operations, usually called addition and multiplication, and denoted by + and ·, respectively, such that the following axioms hold; subtraction and division are defined implicitly in terms of the inverse operations of addition and multiplication"

<comment><USER16> omra likely did not downvote your question.

</comment></comment></comment></comment><comment><USER17> Just like there is a relatively clear separation between electrical engineering and software engineering, I'm starting to think that we need separate words for this kind of stuff and for hacking up a CRUD-some-tables MVP using Ruby on Rails. They're nearly entirely unrelated skills.

I, for one, am very happy that I do not need to think about this stuff. I think that rounding a float to an integer is super easy:

        5.3.round

</comment><comment> v-yadli Now that we know floats have coarse granularity on large scale, why not reduce the scale first?

float fr = (int)f; if(f-fr>=0.5f)fr+=1.0f; return fr;

It works for all the examples in the article. I'm not saying that I've created a good solution. I'm saying that the author is trying to create a problem out of nowhere.

Thought it would be an article to teach people how to manually do float rounding according to a specific fp encoding scheme... :-(

<comment><AUTHOR> This is a good solution that I did not think of at the time. But it is no less expensive than the final (int)(f + 0.49999997f), to compare apples with apples (both still need to be guarded against overflow in the conversion).

</comment></comment><comment><USER18> I don't think that _better function that works_ actually works flawlessly; when passed a NaN or -Infinity, it triggers undefined behavior.

Still, this is a nice article.

<comment><AUTHOR> The contract says that you have to call the function with 0 <= f <= FLT_MAX. So if you call it with Nan, any infinity, or a negative number other than -0 (which happens to satisfy 0 <= f), you are using it outside its specifications.

In that, it is like a standard library strlen(). It does not work if you pass it NULL because it's specified as accepting well-formed strings.

</comment></comment><comment><USER19> There are lots of cute tricks for rounding to integer and to integral values. A few of my favorites:

1\. Round to an integral value according to the current rounding mode, allowing inexact to be set (rintf( ) in C, pretty close to what Pascal is going for in his example):

        // All suitably large floats are integral already.
        if (fabsf(x) >= 0x1.0p23f) return x;
        // Otherwise we can force rounding to occur in the
        // units position by simply adding and subtracting
        // 2**23 with the correct sign.
        const float forceRound = copysignf(0x1.0p23f, x);
        return x + forceRound - forceRound;

If you want the result as an integer and it's in the [-2^23, 2^23] range, you can just rip out bits 0:22 of the floating-point representation of x + forceRound via a mask, which is really simple (faster than hardware convert- to-integer instructions on some architectures!).

If the calls to fabsf and copysignf look like hazards to you, keep in mind that good compilers lower them to one or two bitwise operations on most architectures (though I tend to write these routines in assembly to avoid any risk of missed optimization).

2\. Round to nearest, ties away from zero (roundf( ) in C, which can be annoying because it doesn't correspond to a hardware rounding mode on most architectures):

        // All suitably large floats are integral already.
        if (fabsf(x) >= 0x1.0p23f) return x;
        // Now that we know (int32_t)x cannot raise invalid,
        // we can use that to get truncf(x).
        const float truncated = (int32_t)x;
        // Compare the residual to 0.5 to determine if the
        // result needs to be adjusted away from zero.
        if (fabsf(x - truncated) >= 0.5f)
            return truncated + copysignf(1.0f, x);
        return truncated;

This is also a pretty close analogue to what Pascal was considering. I like my implementation more because it doesn't spuriously raise the inexact flag (whereas Pascal's implementation does). This still isn't a complete implementation of roundf( ), as it gets the sign of zero wrong when the result should be negative zero. Left as an exercise to the reader.

3\. Since people asked about doing the rounding using integer operations elsewhere in the discussion: assume the input is known to be in the interesting range already, and that we have some utility functions for converting between a floating-point number and its encoding (which is a NOP architecturally, but requires a union or memcpy or other type-punning in C):

        const uint32_t xRep = toRep(x);
        const uint32_t xAbs = xRep & 0x7fffffff;
        const uint32_t xSgn = xRep & 0x80000000;

        // If |x| > 2**23, or x is Inf or NaN the result is x.
        if (xAbs > 0x4b000000) return x;

        // If |x| < 1.0f, the result is +/-0 if |x| < 0.5f and
        // +/-1 otherwise.
        if (xAbs < 0x3f800000) {
            if (xAbs < 0x3f000000) return fromRep(xSgn);
            return fromRep(xSgn | 0x3f800000);
        }

        // Otherwise, use the exponent of x to identify the
        // units bit of x.
        const int exponent = xAbs - 0x3f800000 >> 23;
        const uint32_t unitsBit = 0x00800000 >> exponent;
        // "Add 0.5 to x" by adding half the units bit to the
        // encoding.  If this doesn't change the exponent it
        // really is equivalent to adding 0.5.  If it carries
        // into the exponent, then it's not actually the same,
        // but it still does what we need it to do.  After
        // "adding 0.5", we simply mask off the fractional
        // bits to get the result.
        return fromRep(xAbs + (unitsBit >> 1) & -unitsBit);

This doesn't set inexact, obviously, which makes it unsuitable for some uses (but actually nearbyint( ) is _required_ not to set inexact, so this is pretty useful there). It's actually even less code than it looks like; C tends to make this sort of thing relatively verbose. On ARM a complete implementation is about 12 instructions, for example.

N.B. although I write this sort of stuff professionally, I'm just sketching code here without even checking if it compiles. Test before use.

<comment><AUTHOR> I notice that your bit-twiddling version avoids the conditional branch for choosing whether to round up or down. Nice, but not easier to explain.

(0x00800000 >> exponent) is easier to explain that what I did (1 << (23 - e)).

> C tends to make this sort of thing relatively verbose.

If this were assembly, there would be a chance that the test for whether to return the argument without change can be factored with the computation of the quantity (23 - e) (which would be computed directly from the unbiased exponent), so I would really have to try both before deciding on a variant.

> although I write this sort of stuff professionally,…

Since you are reading this (assuming you are reading this), may I ask you what tools you use? I have been making do with CRlibm and a good C compiler, occasionally relying on long double when extra precision was needed, but it has been close to inadequate a few times.

Is there a standard multi-precision floating-point calculator that all floating-point experts use for quick computations, with hexadecimal input and output, or does one have to build one's own? I was thinking of forcing myself to learn either bc or Gappa, but they both seem to have horrible syntax (that is, not a syntax similar to something I'm used to).

<comment><USER19> > If this were assembly, there would be a chance that the test for whether to > return the argument without change can be factored with the computation of > the quantity (23 - e) (which would be computed directly from the unbiased > exponent), so I would really have to try both before deciding on a variant.

It works out exactly as you suggest.

Tools: MPFR and GMP are extremely useful if using GPLv3 code doesn't pose a problem for you and the small performance overhead of arbitrary-precision isn't an issue. I have a small "big float" (not arbitrary precision, just more than enough digits than needed to design math library routines for "standard" precisions) library that I wrote myself. It's not very complete but it has everything I need for library development.

</comment></comment></comment><comment><USER20> Aside from what other commenters have said, this article seems to totally ignore negative numbers.

<comment><USER21> The article explicitly says

"For the sake of simplicity, in this series of posts, we assume that the argument is positive and we allow the function to round any which way if the float argument is exactly in-between two integers."

As a result, adding the condition

        float myround(float f)
        {
            if(f < 0) return -myround(-f); /* <-- the fix */
            /* ... */
        }

suffices

<comment><USER20> My mistake, I didn't notice that.</comment></comment></comment>


What Spectre Means for Lanugage Implementers [video] - <AUTHOR> https://www.youtube.com/watch?v=FGX-KD5Nh2g <comment><USER2> > Conclusion:

> * Programming language implementations _cannot establish confidentiality_ on > today's hardware

> * Don't run untrusted code in the same process with secrets it could steal

I understand that because of this, browsers are moving towards running untrusted JavaScript code in separate processes, so that confidentiality is provided by process boundaries.

Does anyone know whether other applications that embed scripting languages and run untrusted code (e.g. games that embed Lua[JIT]) are also moving towards a multi-process architecture?

<comment><USER3> Doesn't Spectre work across process boundaries?

<comment><USER4> I think you mean Meltdown.

[https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...](https://en.wikipedia.org/wiki/Meltdown_\(security_vulnerability\))

<comment><USER3> No. Meltdown allows for reading kernel memory, subverting traditional memory isolation techniques. Spectre abuses speculative execution to perform side- channel attacks to leak information in general, including across process boundaries.

</comment></comment></comment></comment><comment><USER5> Only tangentially related: what does Spectre means for single address space OSs (Midori, Singularity)?

<comment><USER6> It's game over for them, until hardware offers mechanisms to close these side channels.

</comment></comment><comment><USER7> That's a very weird typo for language. Usually we can tell what word was meant if some letters are missing from what I understand, but for some reason this one was surprisingly bad.

<comment><USER8> I felt there was enough context to parse correctly because:

\- Spectre is a well known vulnerability in speculative execution

\- I know that speculative execution bugs had compiler workarounds involving how you do your jumps (retpoline etc.)

\- "language implementer" is a common synonym or overlapping term with "compiler author"

<comment><AUTHOR> oh, very clever

<comment><AUTHOR> wait, we're making a joke about "lanugage" being a result of out-of-order execution, right?</comment></comment></comment></comment>


Ryan Stewart's Content Marketing Dashboard - <AUTHOR> http://webris.org/content-marketing/analytics

<comment><AUTHOR> Are content and inbound links the only way a new startup can get some SEO creds?</comment>


Let's Talk About Fake News - <AUTHOR> http://newslines.org/blog/lets-talk-about-fake-news/ <comment><USER2> I'm curious to see if this article will be tagged as 'fake news' on Facebook.</comment>


PolyConf 15: Unikernels [video] - <AUTHOR> https://www.youtube.com/watch?v=zi2TdMXs7Cc

<comment><USER2> I wrote up a post about the event with some additional information, which now has a few clarifications/errata at the end. I'd welcome any feedback!

[http://amirchaudhry.com/unikernels- polyconf-2015/](http://amirchaudhry.com/unikernels-polyconf-2015/)

<comment><USER3> I really want to start using unikernels but I'm not sure where to start. I really like MirageOS but being limited to OCaml is a barrier to entry for me. As an alternative, I'm looking at OSv because it works with the JVM. And lastly, I'm keeping an eye out on hyper.sh because I feel like it can conceptually solve some of the same problems as unikernels, except leveraging existing investment in docker.

As a dev with most of my experience being in JavaScript, Java, and Python, is there any advice you could give me?

tia

<comment><USER2> Have you come across Rumpkernel? I'd recommend looking at that since it can work with legacy code. There's a static-website tutorial that describes how to use Nginx as a unikernel.

[http://rumpkernel.org/](http://rumpkernel.org/)

[https://github.com/rumpkernel/wiki/wiki/Tutorial%3A-Serve-a-...](https://github.com/rumpkernel/wiki/wiki/Tutorial%3A-Serve- a-static-website-as-a-Unikernel)

<comment><USER3> tyvm!</comment></comment></comment></comment>


If Ethereum Isn't a Security Then Nothing Is - <AUTHOR> https://mechanicalmarkets.wordpress.com/2018/03/13/ether-is-a-security/ <comment><USER2> Coin Center isn't an unbiased source, but they do have the advantage of actually being lawyers: [https://coincenter.org/entry/no-ether-is-not-a- security](https://coincenter.org/entry/no-ether-is-not-a-security)

Full disclosure: I am also a lawyer, and I work in markets trading at a bank. That's not an endorsement of Coin Center's conclusions, but it's my informed opinion their arguments are sounder than the idle speculation of the author.

If there's anything that Ether is similar to, it's a currencies (my area), collectibles, or commodities (adjacent to my area). There's no underlying business that's being invested in or paying dividends to you. It's 100% a speculation on appreciation.

I'll give you an example. Say Vitalik owned a oil exploration company, and he also owned oil rights to a big patch of oil in Texas somewhere. Instead of selling shares in his company to raise money, he pre-sells the oil. "You give me money for the oil, and I'll go dig it up for you."

You don't own shares in his company. You own oil. Oil isn't a security.

<comment><USER3> I respectfully disagree. As a fellow lawyer, I think it's the standard legal answer...maybe.

Oil is a commodity and as described by you that transaction wouldn't be a security. However, the way you frame it:

>There's no underlying business that's being invested in or paying dividends to you.

>You don't own shares in his company.

You make it sound that only equity/shares are securities, which isn't the standard.

>It's 100% a speculation on appreciation.

While there is massive speculation, that's not the standard either, and I don't think your factual conclusion is accurate either. The investors are relying on the efforts of others for their profits. The article you link concludes Ether isn't a security because the investors aren't relying on the issuer/promoter rather 3rd party developers. But case law doesn't limit the reliance to the promoter it specifically uses the word "others", but even so, I think it's easily argued investors are relying on the foundation to bring 3rd party developers to the table.

At the end of the day...the SEC could have done a Howey analysis on Ether itself, which in my opinion would have been much more interesting and informative than the SEC retroactively doing an analysis on the DAO.

<comment><USER2> > The investors are relying on the efforts of others for their profits.

Are investors in gold relying on the efforts of others for their profits? After all, there are people out there making gold exchanges, developing gold mines, marketing gold jewelry, minting coins and bars for vaults, etc. etc. There's your efforts of third parties which drives up value of gold.

Of course the answer is "maybe" until the law is written or the case decided, but let's not lose sight of the fact that the law already has categories that are a closer fit.

Who's the third party in a decentralized ecosystem? Everyone who's ever contributed a line of code? Everyone who has developed a DAPP that feeds the demand side of the market?

Where's the common enterprise that's being invested in?

<comment><USER3> Well as lawyers we know why gold isn't a security according to case law, and that logic definitely doesn't apply to Ethereum/Ether.

>Where's the common enterprise that's being invested in?

The DAO was a decentralized ecosystem and yet the SEC issued an opinion. So what in your mind distinguishes Ether from the DAO tokens and makes Ether deserve to be treated like gold or another commodity like oil?

</comment></comment></comment></comment><comment><USER4> This is thorough and useful research, thanks for posting it here. Too often people weigh in without reviewing the relevant material.

I have X-Posted it to [https://www.reddit.com/r/ethlaw/comments/8hpjbx/if_eth_isnt_...](https://www.reddit.com/r/ethlaw/comments/8hpjbx/if_eth_isnt_a_security_then_nothing_is_indepth/) for feedback.

(I started this subreddit last year to encourage those who have a legal education or experience to comment on issues emerging in the community.)

</comment><comment><USER5> i think this post is idle speculation, as the author himself admits:

"I'm not a lawyer, and not the right person to be making this argument". Case closed.

<comment><USER6> This appears to be an obvious appeal to authority. An individual's qualifications have no bearing on the soundness of their arguments.

Further, the term "lawyer" doesn't mean that someone is entitled to practice law; merely someone educated in the law. A lawyer is typically (but not always!) someone who has attended a law school. An attorney is someone who has passed the bar exam and is therefore entitled to practice law in that jurisdiction.

All attorneys are lawyers, but not all lawyers are attorneys.

Note that a lay person who has devoted the time necessary to know and understand the law can be termed a "lawyer". I would argue, based on the quality of the article the author is in fact a lawyer despite their assertion that they are not.

<comment><USER7> This is not how people use the terms "lawyer" and "attorney" in practice — at least in for a lay audience, they're equivalent.

</comment></comment></comment><comment><USER8> Title of article is misspelled. Its 'Ethereum'.</comment>


Show HN: Halfchess – Twenty20 of the chess world (apps) - <AUTHOR> http://www.halfchess.com <comment><AUTHOR> I have been working on this project for past sometime (on a sabbatical). I have Android and iOS apps built with ReactJS/Cordova. It uses modified p4wn engine to accommodate a new piece - crab in stage 7 (moves zig-zag). Backend is in Nodejs (uses a DI framework known as archiejs [https://github.com/archiejs](https://github.com/archiejs) \- that I wrote). Leaderboard uses heroiclabs API (heroiclabs.com). It is hosted on gcloud - <USER2> engine(1-5 insts), a mongodb db cluster (2 insts) and redis cache (1 inst). Everything is g1-small instance for now. I am using Tappx (tappx.com) and Admob add networks for monetization. I will be happy to answer and take feedbacks on technology, product, etc... Do ping me here.

* Rule to remember while playing - stalemate is not a draw.

(Also note, I can be approached for remote development work - nodejs, reactjs, fullstack - flipflopapp.com/files/NavalCV_short.pdf).

</comment><comment><AUTHOR> Direct link to apps

Android :

[https://play.google.com/apps/testing/com.flipflopapp.halfche...](https://play.google.com/apps/testing/com.flipflopapp.halfchess)

iOS :

[https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftw...](https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=1182813218)</comment>


When a text can trigger a lynching: WhatsApp and incendiary messages in India - <AUTHOR> https://www.reuters.com/article/us-facebook-india-whatsapp-fake-news/when-a-text-can-trigger-a-lynching-whatsapp-struggles-with-incendiary-messages-in-india-idUSKBN1JL0OW <comment><USER2> WhatsApp is really a multi-faceted platform in India. It's used by schools to send instructions to parents, used by parents in group chats, used by college students to discuss their classes, used for complaints to the authorities in some cases, used by authorities to broadcast messages to people in some cases...and it also happens to be _the premier platform_ for spreading hoaxes, scams, junk forwards and fake news.

I usually tell people not to believe anything that comes on WhatsApp, because that's how low the general quality of conversation on it happens to be when it's looked at in totality.

The Indian government has been curbing free speech and attempting to increase its control on speech over time. People have been wrongly arrested and punished for liking something on Facebook, forwarding something on WhatsApp (that those in power don't like), etc. These incidents only serve to add more fuel to the government and many citizens who actually support higher control and monitoring of all conversations.

In the last four years of this central government, the rhetoric of "you don't have to worry if you have nothing to hide" has been doing the rounds among many citizens who would otherwise not support such measures if some other parties were in power. It's as if they can't see the issues or don't want to see the issues.

If not for the Supreme Court, which runs on its own pace and rhythm, India would've become an authoritarian "democracy". The only hope, IMO, lies with the judiciary. No political party is different on these lines. Whoever comes to power wants more control and power.

Without better education and awareness (with even the so called educated people falling hook, line and sinker to fake news), there's not much hope. It's worrisome how much ammunition these incidents provide to the government to curb speech.

P.S.: India has a restricted form of free speech, where vague terms like public order, affecting the sentiments of others on religious grounds, and such can be legally used to deny speech and also punish people arbitrarily.

P.P.S: India doesn't yet have a data privacy law either. The very concept of privacy was laughed at for quite sometime, until August 2017 when a constitutional bench of the Supreme Court declared that the constitution, through various articles, does grant privacy as a fundamental right.

<comment><USER3> > P.S.: India has a restricted form of free speech, where vague terms like > public order, affecting the sentiments of others on religious grounds, and > such can be legally used to deny speech and also punish people arbitrarily.

That's putting it mildly.

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

[https://freedomhouse.org/report/freedom- net/2017/india](https://freedomhouse.org/report/freedom-net/2017/india)

[https://www.engadget.com/2017/08/29/india-shut-off- internet-...](https://www.engadget.com/2017/08/29/india-shut-off-internet- maintain-order/)

<comment><USER4> For a low income developing country, India has relatively higher freedom of speech that you'd expect.

</comment></comment></comment><comment><USER5> The headline and article are written as if it's somehow outrageous that a text could do this, but when an old-school verbal shout can trigger a lynching, if anything, it would be a letdown if an electronic message couldn't.

<comment><USER6> Exactly. This has nothing to do with the form of communication. The digital nature makes it merely public and accessible to a very large audience

</comment></comment><comment><USER7> New communication methods can be used for the same things as old communication methods. This is not surprising.

</comment><comment><USER8> As an Indian who runs several political groups this is at best shoddy reporting by foreign media. Often NGOS in USA use this kind of news reporting to generate more donations for themselves by showing this poverty porn to their rich donors.

Lynchings do not get triggered by text. Indian people, even the poorest ones are not that stupid. Most often it is a case of genuine crime that the government fails to address. Recently two people of lower castes were badly beaten up for "using water of higher caste".[1] In reality the owner of the well was of even lower caste. The boys were swimming and pissing in the only well the entire region had of drinkable water. After several complains and requests the owner took matters into his own hands.

For almost every single lynching that media reports as "whatsapp driven", the further detailed investigations point out either deep personal grudge, network of crimes such as cow thefts or pure political murder disguised as mob justice. I have not come across 1 single instance were people just killed someone for a whatsapp message.

[1] [https://economictimes.indiatimes.com/news/politics-and- natio...](https://economictimes.indiatimes.com/news/politics-and- nation/2-dalits-caned-paraded-naked-in-maharashtra-for-swimming-in-well-of- upper-caste-man/articleshow/64595266.cms)

<comment><USER9> Whenever any criticism of India turns up online a vocal and combative section always turns up dismissing all criticism as some bizarre media conspiracy. Eventually the thread gets flagged and it goes off the front page.

What are you even trying to argue ? That the lynchings might have legitimate reasons ?

Doesn't change the fact that they are lynchings.

Many parts of rural India are quite lawless and mob justice is the rule. You can be killed for the mere suspicion of having killed a cow.

Now fake videos circulating via WhatsApp have worsened the problem.

Even a cursory google search can find evidence of WhatsApp lynchings

[https://www.bbc.com/news/world-asia- india-44435127](https://www.bbc.com/news/world-asia-india-44435127)

<comment><USER10> A lot of noise/hatred/fear is also generated for all sorts of reasons by hiding facts and portraying a very particular picture.

But what you are saying is also true. Do you think it's only India/Indians though?

<comment><USER9> I'm Indian myself and I agree it doesn't feel good to see your country constantly stereotyped by Westerners.

But we don't need to be defensive either. India is the largest functioning democracy on the planet and that's nothing to sneeze at.

Some international exposure on such problems might atleast convince those in charge to do a better job keeping things under control.

If India wants to join the league of the US EU etc then we must be prepared to be judged on those metrics.

China is getting more autocratic by the day and apart from the occasional post no one is as concerned because it isn't really expected of them to hold up to democratic ideals.

<comment><USER8> > If India wants to join the league of the US EU etc then we must be prepared > to be judged on those metrics.

Sorry. I do not agree at all. You think India can crawl on all 4 and these countries will give India a seat at the white people's club ? India will not win by playing into the hands of euro-us centrism. Our problems are ours to solve and US/UK etc. should butt out.

<comment><USER9> Well acknowledging actual issues isn't crawling on all fours.

This isn't about a seat at the white peoples club either.

International pressure has achieved many productive outcomes like the ending of Apartheid for example.

</comment></comment></comment></comment></comment></comment><comment><USER11> Freedom of speech, like all freedoms, requires discipline and comes with costs. Sometimes those costs are tragically high, but freedom is worth it because the altenative is even worse.

I wonder why this logic is rarely applied to the second amendment? Guns can be used for tragic purposes, but also allow vulnerable people to defend themselves when the police can't or won't. Nobody is really sure whether they can prevent the next tyranny, but we're pretty sure that tyrants or slaveowners don't want their subjects armed.

<comment><USER12> Speech is an intrinsic quality of people, with purposes as diverse as thought and central to human expression. Guns are tools to kill something, and while they can in theory be used to kill or threaten to kill in a myriad of situations, they are still just killing machines. Most of human history hasn't included them, they are not intrinsic abilities of nearly all humans, they're not central to the ability to teach, learn, communicate, etc.

That's not to say guns aren't important, or rights to guns shouldn't be protected. It is saying however that comparing speech and guns makes apples and oranges comparisons look downright apt.

<comment><USER11> What test are you using to determine which rights are valid and which aren't?

You point out some differences, but who's to say those mean one is a right and one is not?

You could say something similar about abortion, for instance. Throughout most of history abortions were not available and certainly not in a safe form. But now they are recognized as a right.

<comment><USER12> I'm not judging the validity of rights, I'm examining the practicality of embracing those rights up to their logical extremes. I didn't despute the right to self defense, I just pointed out that as written by the person I replied to, it coils just as easily be applied to tanks and rocket launchers.

It's possible to be far more permissive with freedom of speech than it is with free access to modern weaponry.

</comment></comment></comment></comment><comment><USER13> Another variation of toxic social media, 'fake news', and misinformation/propaganda, which is ubiquitous online and only growing.

In the current internet environment, it's best to assume everything seen, found, rumored, or heard online is fake until proven otherwise.</comment>