Top Twenty Sites: Most Downtime - <AUTHOR> http://www.techcrunch.com/2007/04/02/top-twenty-sites-most-downtime/ <comment><USER2> Wait wait, myspace alone was down for way more than an hour. Often at least one of its services is down. Same for many of the other top sites.

They must be more thorough with their measurements.</comment>


USDA.gov Backlinks to Adult Sites - <AUTHOR> I was looking to see how some websites get .gov backlinks - most are legit, but for usda.gov I noticed a few adult sites.
https://drive.google.com/file/d/1LI0ouRcTxHrWF67s6KZxCpKq74aBavCu/view?usp=sharing
On a scale from 1-10, how much does this impact an adult site's organic rankings? <comment><USER2> Receiving high quality backlinks from .gov sites can dramatically increase your website rankings, but actually getting those powerful backlinks is a monumental task. Although there remains some debate over the true value of .gov extensions with Matt Cutts stating, "Google doesn't treat .gov or .edu domains any differently," most SEO professionals feel otherwise.

Google may not view them any better than .com. .net, or .org, but the authority factor .gov links hold gives them extra SEO power. While Google won't give a definitive answer regarding the power of .gov links, they are considered to be the holy grail of backlinks because they are established and trusted sites.

Best Regards, Band1to

</comment><comment><AUTHOR> Actually here's a imgur image: [https://imgur.com/a/j9YjClB](https://imgur.com/a/j9YjClB)

<comment><USER3> Instead of screenshots, why not provide the actual .gov link?

<comment><AUTHOR> I found it using the AHREFs backlink checker program - I'm not very technical so I don't know which pages the link is on</comment></comment></comment>


Ask HN: What can I do to make sure that I don't lose my coding skills - <AUTHOR> I studied computer science and did a couple of software development internships as a student. I love programming and building stuff however less than a year after graduating, I'm working in marketing for a tech company and writing code is not part of my job description.
These days I hardly write code and it eats away at me. What can I do to make sure I don't lose interest in coding or lose my coding skills? <comment><USER2> First Choose a framework you enjoy working in.

I always recommend Rails or Laravel since I enjoy those.

Then build a basic web app to scratch an itch you have.

ToDo/Planner, Private Social Network for your close friends or family, Budgeting Tool, Tracking something you collect (Albums, Legos, etc), geo location is interesting, QR Codes maybe a scavenger hunt app for you and your friends (setup QR codes around town with clues).

Whatever you choose, use it, extend it, update it over time, keep a list of features and improvements you want to do. When you feel like coding pick one and implement it.

If you lose interest in your app. Start a new one.

If you want learn React, Angular or Vue on top of a Rails/Laravel app.

Buy a domain, use Git, Deploy your app to Digital Ocean to build up your skills/knowledge.

If you're interested checkout the StartUpsForTheRestOfUs podcast if you have an interest in starting your own thing eventually.

Good Luck, have fun keeping your coding skills sharp.

</comment><comment><USER3> Pretty much what other have said: if you want to retain the ability to code, you're going to have to keep coding. The bare minimum would be running through the exercises on various coding sites, such as HackerRank. What would be best is to devote a weekend a month (more if you can afford the time) to actually building something, be it a mobile app, web site, etc. for something that interests you.

Also, bear in mind that the farther along you go in your career, the harder it becomes to switch tracks. If you go more than a decade without coding professionally, it may be hard to get yourself considered for a coding job by many employers without an exceptional demonstration of your coding skills.

</comment><comment><USER4> I feel like there's a point you hit where once you code enough you will NEVER forget how to code. All these patterns and concepts are burned into my brain with the power of 1000 suns. Even if I wanted to I couldn't forget.

</comment><comment><USER5> I will have to disagree with the previous answers. You don't have to WRRITE code to stay up to date. You can READ one or more books about programming. That's what I do, and it is a thousand times more efficient than simply writing code just for the sake of it, because you get to learn new stuff in the process.

</comment><comment><USER6> Programming.

I forget the code I wrote last week and how it works.

Gotta keep coding.

<comment><USER5> Then you didn't fully understand what you were writing in the first place.

</comment></comment><comment><USER7> Code things?

I'm not trying to be a snarky asshole: the best thing you can do is build some things.

Maybe you can start by automating some chore you do for work.</comment>


SHRDLU - <AUTHOR> http://en.wikipedia.org/wiki/SHRDLU <comment><USER2> Maybe it's also good idea to revisit the reason why these systems are not widely in use. They all operate under so called "closed-world" assumptions. It means that the knowledge about the world is very limited.

Once the limitation is lifted the system has to deal with non-monotonic reasoning ([http://en.wikipedia.org/wiki/Non- monotonic_logic](http://en.wikipedia.org/wiki/Non-monotonic_logic)) and that leads to multiple inheritance problem ([http://en.wikipedia.org/wiki/Multiple_inheritance](http://en.wikipedia.org/wiki/Multiple_inheritance)). Unfortunately, the multiple inheritance problem has, so far, only NP-hard solutions ([http://ijcai.org/Past%20Proceedings/IJCAI-89-VOL-2/PDF/047.p...](http://ijcai.org/Past%20Proceedings/IJCAI-89-VOL-2/PDF/047.pdf)). [EDIT: think of a command "eggs are in a fridge"; to find eggs in a fridge you need to know that they are inside a container; you need to know its shape and how to open it; if your software knows that and inherits this knowledge each time when asked for eggs, then it will brake when the eggs are not in the box.]

We are in need of software that deals with large networks of human knowledge. Then we can take SHRDLU to the next level. Otherwise we are stuck with Will Smith movie ([http://www.imdb.com/title/tt0343818/](http://www.imdb.com/title/tt0343818/)).

[EDIT2: there are many theoretical "suggestions" but very little software or practical internet applications]

<comment><USER3> Why are close-world assumptions bad for all cases? There might be cases limited to a domain where the computer does not need to know about the world too much. Consider, the language of geometry problems given in high school math books. Surely, to understand that, one doesn't need to have world knowledge, but only ideas about what intersect means, and so on. This way, SHRDLU can be modified to understand geometry problem statements. The same way, it could also work for other domain-limited applications. A general solution might have to go to probabilistic systems, as current research suggests.

</comment></comment><comment><USER4> 1\. So yes its intelligence is highly specific but it certainly seems like a program like this could be evolved to become very useful for some application. Why hasn't that happened?

2\. One big problem when interacting with systems like this I suppose would be that you have to know what is supported by its grammar in order to use it. The best solution I can see to that problem would be to add some sort of smart as- you-type suggestion feature. Making it smart enough would require some research of its own though but probably well worth it.

edit: Somewhat related is a tool for working with grammar for computer applications (parsing and translating between abstract and concrete and between different concrete representations): Grammatical Framework ([http://www.grammaticalframework.org/](http://www.grammaticalframework.org/))

</comment><comment><USER5> Related: [http://commonsensereasoning.org/winograd.html](http://commonsensereasoning.org/winograd.html)

Page 290 of the dissertation [1] discusses ambiguity in words and phrases. The Winograd Schema challenge as defined by Hector Levesque poses questions like "The ball could not fit through the hole because 'it' was too big. What was too big?"

These questions are obvious to humans, but difficult for computer programs to answer, because "it" may refer to multiple objects. If SHRDLU gets confused, it may ask for clarifications from the human, or make its best guess and assume that "it" refers to the green cube rather than the blue pyramid.

[1] - [http://hci.stanford.edu/winograd/shrdlu/AITR-235.pdf](http://hci.stanford.edu/winograd/shrdlu/AITR-235.pdf)

</comment><comment><USER6> Just that abbreviation brings back good memories to a CS practicum in which we needed to write a language parser and virtual world manager in Prolog. Especially building the memory functionality -- "place the blue ball on top of the red cube", "move the ball to the right" \-- was fun, taking into account the vague reference to earlier objects and possible/allowed movements. Man, I need to find that code just to enjoy the memories...

</comment><comment><USER7> It is very interesting to (re)discover software like that! IMO lot of things have been invented in the 70s and we always reinvent the wheel!

</comment><comment><USER8> The source code is very well commented, a high quality piece of engineering.

<comment><USER9> It's seems to be in a Lisp dialect that predates common lisp unfortunately.

<comment><USER10> Fortunately it is the Lisp dialect much of Common Lisp was based on: Maclisp.

<comment><USER9> And is there a way it from my machine without installing MacLisp? is there some way to translate MacLisp into Common Lisp?

<comment><USER10> There are already SHRDLU versions in Common Lisp.

</comment></comment></comment></comment></comment><comment><USER11> More information including images of graphical 3-D version: [http://hci.stanford.edu/winograd/shrdlu/](http://hci.stanford.edu/winograd/shrdlu/)

and an online version of part of the system [http://www.grammaticalframework.org/~peter/shrdlite/shrdlite...](http://www.grammaticalframework.org/~peter/shrdlite/shrdlite.html)

<comment><USER12> Thanks—we changed the url to that first one from [http://en.wikipedia.org/wiki/SHRDLU](http://en.wikipedia.org/wiki/SHRDLU).

<comment><AUTHOR> And yet the original pointed to an article that has a better overview, some details _not_ in the one you changed it to, and more, actually contains the link that you've now set it to.

In short, you've replaced a link to an excellent overview that has a link to more material, with a less useful link. I know we have our disagreements, but this just seems out and out wrong. As I've said before, I find this immensely frustrating.

<comment><USER12> Ok, we've changed it back.

Please follow the HN guidelines and email us when you have a complaint about moderation. Procedural nitpicking in the threads makes them worse.</comment></comment></comment></comment>


Remove the ugly iCal styling in OS X Lion - <AUTHOR>

http://noahhayes.com/ical/resources.zip
This is a quick fix for those of you who have been using the latest build of OS X Lion's iCal and don't like the new leathered journal styling. I personally find it to be quite ugly and wish they had just used the default grey gradient styling.
To fix the styling, just paste these zipped images into the resources folder of iCal's package content folder (right click on the iCal app and click "show package content", then go to the resources folder). <comment><USER2> <http://noahhayes.com/ical/resources.zip></comment>


Feds Hunted for Snowden in Days Before NSA Programs Went Public - <AUTHOR> http://www.reuters.com/article/2013/06/12/us-usa-security-snowden-hunt-idUSBRE95B1A220130612

<comment><USER2> It looks like even Reuters engages in link baiting now. This is a non-story. In the original Guardian article, Snowden says that the FBI was at his house asking questions before the release, but only because they were concerned about his disappearance.

> When Booz Allen checked in with him, Snowden said he was suffering from > epilepsy and needed more time off. When he failed to return after a longer > period, and the company could not find him, it notified intelligence > officials because of Snowden's high-level security clearance, one of the > sources said...The government did not know Snowden was the source for the > stories until he admitted it on Sunday, the sources said.

So the Feds "hunted" for him the same way a parent "hunts" for his child that has wandered off in a store.

<comment><USER3> >>So the Feds "hunted" for him the same way a parent "hunts" for his child that has wandered off in a store.

That's a fatuous analogy. Parents aren't primarily concerned with getting to their kid before the kid tells some "stranger" something.

<comment><USER4> You missed his point, which was that the Feds weren't worried about him telling a stranger anything, until later.

<comment><USER5> I doubt this is true. When someone with that kind of clearance disappears the feds are going to put some effort into trying to figure out what's going on. That someone may have turned him is a possibility they have to consider, among others.

</comment></comment></comment></comment><comment><USER6> "This guy's really good with his fingers on the keyboard. He's really good."

Not sure about CIA or Booz but at every company I've worked at a good sys admin can get anything.

<comment><USER7> If you have the keys to the house you might as well look around...

<comment><USER8> Except the sysadmin is more like a housekeeper than a random guy with keys. Yes, they will see everything and can access just about everything.

</comment></comment></comment><comment><USER9> This is a strange and ambiguous statement, I think:

> _Several sources said that as a systems administrator, Snowden would have > been unable to actively spy on people, even though he told the Guardian > newspaper, "I, sitting at my desk, certainly had the authority to wiretap > anyone, from you or your accountant, to a federal judge, to even the > President."_

What does "actively spy on people" mean in this case? As a systems administrator, did Snowden have a way to get to the private data, even illegal or otherwise?

To me what Snowden said, considering his position and assumed competence, what the aforementioned sources say seems to contradict that. However, they might just rely on saying that sysadmins don't have the legal power to do so, or that other sysadmins would notice it even if he breached his privileges and so on, rather than that _there is no way Snowden could have done that_.

A play on words and not revealed meanings might just be turning a fact into fiction here, at least that would be in the best interests of NSA for sure, so there's also the motive for such wordplay.

Or then Snowden is a liar, which I find doubtful, especially in such a clear case and would turn up being harming for his cause.

<comment><USER10> I think the key word is 'active' \- all Snowden could do is sip through already collected data - he could not 'actively' add a new data source.

</comment></comment><comment><USER11> > "Snowden already had a Top Secret clearance before he joined Booz Allen in > April, two sources said, adding that he likely obtained that clearance - > _which involves passing a polygraph exam_..."

I know for a _fact_ that most government top secret clearances don't require a polygraph. Not that it means shit, since polygraphs have never been proven to prove anything. I just hate when I see things written by "credible" people that will be taken by fact by hundreds of people when it is not entirely true. Working in environments where all of the fine details are rarely shared, you see this a lot in the media.

Law enforcement in general (Anywhere from city to FBI) is known to give polygraphs before a conditional offer of employment is given. However, this is not the case with all agency's.

<comment><USER12> Yeah, but he got that specific top secret clearance from his work as an employee of the CIA. As far as I know, all CIA positions require a polygraph.

<comment><USER13> Yea, all the three letter agencies do.

</comment></comment></comment><comment><USER14> They've misquoted a sentence from the video interview, the same way many others have. Reuters quotes Snowden as saying:

 _" I, sitting at my desk, certainly had the authority to wiretap anyone, from you or your accountant, to a federal judge, to even the President."_

Meanwhile, the way his wording sounded to me (and is quoted more often elsewhere) was:

 _" I, sitting at my desk, certainly had the authorities to wiretap anyone, from you, or your accountant, to a federal judge, to even the President if I had a personal email."_

The differences are the pluralization of _authorities_ and the addition of the conditional-qualifier "if I had a personal email".

Of course people speaking in an unrehearsed manner may mix up tenses, pluralization, and speak with imprecision as they shift between thoughts and chosen emphases. But I suspect those portions of the quote Reuters messed up were significant.

First, it sounded to me like 'authorities' was likely a term-of-art in his intelligence-analyst line of work, meaning specific rule-artifacts in the access system, representing a mix of 'proper credentials' and 'suitable legal/system authorization'.

After all, NSA defenders have given the impression that even though there is a massive amount of data collected, including on US citizens under no suspicion, it's OK because those records sit idle, never looked at unless and until the right conditions are met.

I have a hunch those conditions are called 'authorities'. So when you've got records on individuals A, B, and C, and your algorithms tell you A & B are 51%-plus likely to be US citizens, but C is 55% likely to be a foreigner, well, you can use the longstanding 'authority' allowing analysts of your grade to do warrantless surveillance of foreigners, to start pulling things up on C, from anywhere and everywhere (including previously-bulk-warehoused call recordings, colloquially 'wiretaps').

And then when you see that C has been emailing B, that alone, or perhaps the contents of those messages, might be enough to activate another 'authority' \- suspicion, or association, or content-pattern based - which then allows at least a peek into B's records. Perhaps that peek confirms B is a foreigner - now the identity is marked that way, and it's all wide open. Or maybe the peek shows B to be a citizen... well, now you've got 1 week to ask the FISA court for a warrant. Better read fast! (Open question: if NSA decides after this 'free look' they have no interest in continued surveillance of target person B, does the warrant for retroactive permission ever get requested? Are there any records or repercussions from the 'free look'?)

Of course, the visibility of some target-records might be over-determined: multiple active 'authorities' all allow viewing. Others might require some "good at the keyboard" analyst creativity to activate: is there a past-travel, likely-associations, prior-suspicious activity, etc. 'authority' that could be applied? Still other 'authorities' might only be available to more senior analysts: maybe targets who are themselves state/federal employees, elected officials, etc. have an _extra_ sheath-of-privacy that prevents easy peeks by junior people using the most simple and elastic 'authorities'.

Which brings us to Snowden's other carefully-qualified bombshell: "…to even the President if I had a personal email." Let's say person B above is in fact the US President... perhaps using a separate personal email address. (There is of course controversy about officials having separate email accounts, but it's almost certainly a rampant practice – see especially the recent Petreaus affair and allegations administration officials in the EPA, HHS, or Labor department have used secondary addresses, sometimes under alternate names, for official business or leaking.)

Now using one of the myriad of 'authorities' a skilled analyst can utilize, they can start pulling up warehoused records about B – the President himself – possibly including previously recorded telephone/VOIP discussions linked with the B identity (aka 'wiretaps').

I wonder, then, were 'a federal judge' and 'the President' just vivid hypothetical examples? Or maybe Snowden actually pulled up, or heard that his coworkers pulled up, private conversations of a federal judge or the President himself, using 'authorities' that weren't especially hard to bootstrap, given the surveillance system architecture.

<comment><USER15> I read "authorities" as "clearance" or "permissions", not that the system had green light the sifting of communication of a particular person. My reasoning here is that he mentioned the President as well. It seems that any personal account is fair game so long as you have the permissions to perform a search in the system and you have the personal email to use as a unique identifier.

<comment><USER16> You are correct.

</comment></comment></comment><comment><USER17> You know, the thing that gets me most about all of this state surveillance that Bush initiated but has been in place for decades now to a lesser and more controlled extent, is that it is absolutely inefficient and inefficacious. The NSA claims they have disrupted "dozens" of terrorist plots, so why not publicize them once they are disrupted? They're disrupted, they're done. The "terrorists" would have surely realized their plan didn't go quite as planned.

So the NSA disrupted some plots and turned an asset that simply told their terror boss "bummer, XYZ didn't work because I lost the keys" and he's now snitching for us. That being said, there are surely "plots" that could easily be publicized. The thing people don't realize is that under the blanket of classification lies a heaping pile of shit, corruption, incompetence, and abject stupidity.

Secrecy can protect, but more often than not is simply obscures, disguises, compounds, and perpetuates failure and corruption. Case in point, the FISA "Court" that's rubber-stamping requests. 100% approval??? At the very least there is a far too close relationship, which is more common than not in Government and Military, and is a form of pernicious, systemic corruption, and FISA requests are simply being constructed so they are guaranteed to rationalize approval on technical terms. But I can assure you, there is deep, systemic, putrid rot below the new coat of paint.

</comment><comment><USER18> So, how did they not know he had left the country? IIRC, the airlines now report departures to DHS as well as arrivals (another 9/11-era law).

I think it unlikely that he had a false passport.

</comment><comment><USER19> I wonder if they checked his Facebook messages and Google maps searches.</comment>


Arguments for TPP don't make sense - <AUTHOR> https://www.bostonglobe.com/opinion/2015/05/30/arguments-for-tpp-don-make-sense/W8WNu5IR9xkhzsqYV0pBWK/story.html <comment><USER2> Not to hijack the better points of the article, because it's a good one, but this line is telling:

 _" The White House's efforts to portray the treaty as critical to national security simply underscores its inability to make a case for the agreement on the basis of economic benefits."_

If you can't make a cogent argument, just flail your hands about and yell "National Security!" You wouldn't dare try to impede national security!

Those two words are what remain of Bush's "you're either with us, or against us" brand of patriotism, but it has a choke hold on the U.S. I cannot understand why otherwise smart people continue to let "national security" dissuade all common sense in everything.

Edit: "Investor-State Dispute Settlements" make me want to throw up my hands and move to Mars. I can't fathom how anyone can accept calling ISDS "national security" as anything but pure, black-tar hogwash.

<comment><USER3> > I cannot understand why otherwise smart people continue to let "national > security" dissuade all common sense in everything.

As Upton Sinclair said, "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" It is important to remember an unfortunately large subset of the people making those arguments - including far too many people here at HN - are _profiting from the status quo_.

I am less worried about the people making the stupid "with us or against us" ultimatum (at least those people are predictable). The problem is the far larger group that still refuses to believe that surveillance as a business model even exists, or that the "public-private-partnerships"[1] are anything other than regulatory capture.

Once you realize who the "nationals" are that need to be secured, the TPP/TTIP - and all the other efforts to undermine democracy and replace it with corporate sovereignty - make sense. It is the same thing we saw in Jewel v. NSA, when the government's legal council gave the Freudian slip of the century, claiming that it was important to keep the use of section 215 secrete, because of the need to protect "THE NATIONAL SECURITY OF THIS COMPANY"[2].

As for the ISDS, everybody in the negotiation room needs to remember the advice of Londo and G'kar to their junior assistants as they leave them to handle important negotiations on their own: "Just don't give away the homeworld!"[3]

[1] or whatever the latest buzzword-compliant rebranding of fascism is called

[2] [https://www.techdirt.com/articles/20140813/23203228207/unsea...](https://www.techdirt.com/articles/20140813/23203228207/unsealed- jewel-v-nsa-transcript-doj-has-nothing-contempt-american-citizens.shtml)

[3] [https://www.youtube.com/watch?v=62EaD85zX7o](https://www.youtube.com/watch?v=62EaD85zX7o)

</comment></comment><comment><USER4> The secrecy surrounding the negotiations based on the premise that "We'll see it when it's passed" is absolutely part of the reasons it's been resisted in the way it has. The portions that have been leaked so far seem to suggest it's role is little more than expanding US control over media rights and limiting other countries abilities to produce potentially competing products (Medicines, media etc) which of course means any country with any form of sensible population would want nothing to do with it. Sadly the desires of the population seems to mean little when governments weigh the concerns of big business but still.

<comment><USER5> Global arab spring is at hand. And this is scary ...

</comment></comment><comment><USER6> I'm surprised that the article doesn't spend more time pointing out the sheer arrogance of this, to non-US eyes.

Even the countries who would possibly be signing on to this must be insulted by it. That's not a good place to start.

Nobody else in the world cares about US interests, except insofar as it enriches them and/or prevents them from getting beat up and/or cornholed by friendly, drunk, sometimes generous, often abusive Uncle Sam.

<comment><USER7> When Europe passes TPP it will be the fault of the Americans. Europeans leaders are not held responsible for anything they do and therefore can easily do what the US asks with no fear of repercussions. This is self fulfilling victimology.

<comment><USER8> > Europeans leaders are not held responsible for anything they do

And even when someone tries to make someone responsible, they just say: "Well it's an EU thing. We tried to stop it, but the other countries wanted it". EU in turn points to the individual countries and say: "It's up to the parliament in each member country to interpret and implement the rules". It's the perfect system for not taking responsibility and still have the flexibility to do what ever you want.

</comment></comment></comment><comment><USER9> Especially the "China is out to destroy us" argument. It's funny how each time there is a heated debate in USA, China suddenly looks it is going to invade USA soon ? Even worse, China might join the TPP in the next future. So enough of "but but China..." bull.

The TPP is a excellent deal for multinational corporations,no question, they wrote the deal, whether it's good for your job or your small business here in USA is a different story. People should be able to see the deal right now, because it will have a lot of direct consequences on their lives. Or Obama doesn't trust people's common sense? or he wants that legacy at any cost?

</comment><comment><USER10> Chas Freeman's arguments are always such a joy to read. He is like the Freeman Dyson of politics. I don't always agree with him, but I love the willingness to take viewpoints that piss off both parties.

</comment><comment><USER11> China is setting up a 'New Silk Road' [1], not the darknet one but resurgence of their trade dominance of Asia from the past. China is also benefiting their trade partners in ways that the US doesn't always and we should. The original silk road was known for bringing riches to all points on the routes.

China also has presence in the South China Sea where 2/3rds of all trade go through, it is the reason they are adding new islands there as well. CNN recently had this in the news but it is ultimately protection for the trade routes through the South China Sea.

They have also been diplomatically setting up station in Yemen [2] and Somalia [3] along the Suez Canal trade route. So at major points of the water based trade routes, China is owning them or taking control of them.

China is also building a massive trade route through Pakistan to the Gwadar and Karachi ports in Iran and Pakistan, very close to Iraq + India and near Afghanistan[4]. Completely within Pakistan/Iran, it is another route around the South China sea into/near the Persian Gulf.

The World Trade Organization (WTO) in 2001 left China with huge advantages in exports and currency tools due to large currency purchases in other countries, that are smart for them and bad for the US in terms of running trade in Asia and currency values. We have slipped a bit, largely this is due to short term thinking and overt control of trade partners, while China is very long term. We are giving up alot in the TPP because we never really have, we have to convince countries to trade with us for our advantages and theirs, over what China is offering.

Trade agreements aren't always bad. But the problem in the US now, due to the control of them, they are usually bad for the workers and great for corporations. The problem with the TPP is that corporate riders have attached on in ways that are solely focused in greed, over the workers of the US and protections for US.

You could argue that China lent us the money to get into debt to them to allow them to do this while we were bogged down with wars, unwinnable wars, with force in the Middle East around the same areas.

We forgot how to benefit countries and even our own now. We need more Marshall Plan type liberation through economic advantages for all countries involved (including us) to be a better option for trading partners. China is winning the game, that is why this is fast tracked but it is also bad for the US internally but the other option is losing more trade dominance. Noone wants to join the mean person's team when there is a more friendly option that is mutually beneficial, or to pick sides.

The Yale article on the new Chinese Silk Road (One Belt, One Road initiative) mentions a fundamental problem in our reasoning in this snippet:

 _Will supporting China 's One Belt, One Road, compromise core universal values and high environmental and labor standards? These are key areas where the US can show leadership and remain a keystone of the 21st century global economic architecture. But a keystone must work with other stones rather than stand alone._

It is a pretty easy sell for the Chinese to these countries like Pakistan, Iran etc with us right on their doorstep and without a good economic mutually beneficial plan for the places we 'liberated'. Iraq and Afghanistan should have been nation building as the main goal, but it appears we created chaos a decade later. Force doesn't always work but better quality of life always works, always brings more money. We should leave places in a state like Japan or South Korea, not how we left Iraq/Afghanistan/etc. Now China is also getting defense/military power to contain these areas.

This is a massive world change. We can't change it with force this time, China is everyone's biggest trade partner including ours. It would be better to work it out with them than exclude them. We have to benefit the US and other countries with trade, not take everyone down. China is doing the opposite and the better deal will win.

As a US citizen it is hard to think we benefit others if our trade agreements harm the lower classes in the US so much, what are we doing elsewhere. We used to build good trade partners up and they thrive. What happened?

[1] [http://yaleglobal.yale.edu/content/china%E2%80%99s-new- silk-...](http://yaleglobal.yale.edu/content/china%E2%80%99s-new-silk-road- implications-us)

[2] [http://www.washingtonpost.com/blogs/worldviews/wp/2015/03/31...](http://www.washingtonpost.com/blogs/worldviews/wp/2015/03/31/what- yemens-crisis-reveals-about-chinas-growing-global-power/)

[3] [http://thediplomat.com/2014/07/after-23-years-china-to- reope...](http://thediplomat.com/2014/07/after-23-years-china-to-reopen- embassy-in-somalia/)

[4] [http://tribune.com.pk/story/896213/pakistan-dismisses- indias...](http://tribune.com.pk/story/896213/pakistan-dismisses-indias- concerns-over-china-pakistan-economic-corridor/)

<comment><USER12> If they'd just drop the horrible intellectual property provisions, which aren't even relevant to geo-strategic trade, I wouldn't care so much what kind of geo-strategic trade deal they wanted to negotiate in secret.

<comment><USER13> While the IP sections are horrendous, it's dangerous to ignore the problems inherent with the investor-state dispute section(s). There are already multiple cases involving corporations suing countries for having laws that prevent them from making money in their preferred manner. Increasing the scope or range of those conflicts will strip more nations (including the US) of self-government.

I don't want to come off as hyperbolic, but these provisions can seriously undermine any future legislation and nation might want to undertake in order to protect their resources or population.

<comment><USER14> ISDS complaints can only win if the government is shown to unfairly hobble foreign investors, for example a regulation that says "companies owned by Americans can pollute twice as much as companies owned by Malaysians."

That's not the way that U.S. law works; our laws are based on measurable standards that apply equally to all companies regardless of who owns them. That's why the U.S. has never lost an ISDS case in the decades they have already been in force.

</comment></comment></comment></comment><comment><USER15> Chas Freeman is 100% spot on in this article and provides a sound rebuttal to the portions of the TPP that we've been able to see.

The reason that he is able to so effectively dismantle the economic arguments is because the real intention of the TPP is not for economic benefit of the United States; it is to set up a supra-national framework for supra-national corporations to override national sovereignty.

Compared to the money and power at stake, the cost to buy the political establishment in DC is next to nothing, and so they do it. Ripping the TPP apart as failed policy is good, and I'm all for that... but the problem can really only be solved by hacking at the root, which is the fact that our governments and the rule of law have been hijacked by entities that have no soul to save and no body to incarcerate.

</comment><comment><USER16> TPP is just a funnel for the USA to pour bullshit down the throats of other nations citizens.</comment>


Toshiba claims EV battery breakthrough: 200-mile charge in 6 minutes - <AUTHOR> https://www.autoblog.com/2017/10/24/toshiba-scib-ev-battery-breakthrough-200-miles-charge-6-minutes <comment><USER2> I'm glad this is happening, not necessarily for this exactly, but for the taste of the future it gives us, cause this is only the beginning. We'll get more power, more durability and reliability as the processes are refined add improved upon.

</comment><comment><USER3> I wonder how much the titanium niobium oxide anodes will add to materials costs.</comment>


How to Accept Over-Engineering for What It Really Is - <AUTHOR> https://medium.com/@fagnerbrack/how-to-accept-over-engineering-for-what-it-really-is-6fca9a919263 <comment><USER4> I suspect that quite a bit of the over-engineering I have seen was driven by the personal agendas of some of the developers: turning a boring, run-of-the- mill project into something that feels like you are working on the leading edge of technology; "I have learned all this stuff, now I am going to show I can use it"; the misapplication of design principles for large projects to small ones; resume padding. It is not done by those programmers who struggle to get anything done or by those who always do the least they can get away with out of laziness; it requires a certain level of competence and is driven by ambition.

These motivations seem to be behind many of the almost constant calls for rewrites, but rewrites with no better justification than this rarely turn out to be a good use of resources. It is particularly galling to see a rewrite that is no better than the original.

<comment><USER5> I agree with you. Only the very best developers that I have worked with advocate for principles like: no rewrites, refactor only; less is more; minimal viable product with customer feedback loops; reducing complexity; a/b testing, etc. My best work has been alongside product managers that push back on new features. I have never seen a rewrite that was functionally better than the original.

I honestly don't have any experience working with a team that produces a top- shelf title, like a popular web browser, spreadsheet, or calendar application. I've only been involved working on internal facing "intranet" business applications, because that's where the majority of the jobs are.

That being said, I wonder if what you're describing is worse for internal applications, simply because teams don't really "listen" to their users (employees)? I don't think I've ever seen a nice intranet or internal payroll application, for example. My current company, which is a very big F500 company, has one of the worst payroll and HR apps considering its size. Intranet applications tend to accumulate every departments special hidden feature without anyone keeping it in check.

Looking at Apple I feel that most of their customer facing applications and operating systems are getting worse not better. They are getting too "clever" with their user interfaces, relying on tricky unintuitive user interface gestures and hidden button clicking. I wonder if the symptoms you describe manifest themselves at Apple as UI "cleverness."

<comment><USER6> I've over-engineered plenty of software in my time. Most of the time, it was because of boredom with yet another crud app.

An anecdote about rewriting:

I've also been involved in 4 successful rewrites. The decision to scrap/start over is rarely a good one. In my case, my team had inherited a bizarre suite of apps that combined VB6/C++. It was full of memory leaks, and had never been successfully deployed in the 3-4 years of its existence. We rewrote the entire suite in a year using .NET (1.x at the time). We (developers) went onsite to a bunch of our clients and watched them work, figured out what the system really needed to do, and made it do exactly that. The result was the first successful deployment the company had had in 4 years. It also sold itself in sales meetings, because it had been designed by watching users, rather than by guesswork.

So rewrites can be done. The question is: how bad is the underlying system? And how much easier is the problem to solve in technology X vs Y?

In our case, the underlying system was atrocious, undocumented, untested, written by a COBOL programmer who did not understand VB or C++ or OOP. And the .NET WinForms stack was vastly more productive than the C++ (and even the VB6) stacks we were replacing. The decision to rewrite was pretty easy.

<comment><USER7> This seems successful because It's less a rewrite and more of a build a different solution that actually fits the need.

Which is a good reason to dump something that isn't appropriate any longer. Or, worse, never was appropriate. :-)

</comment></comment></comment></comment><comment><USER8> I believe most experienced software types would agree that maintaining systems over time is a rather different skillset to building them in the first place. 'Fire and forget' is a great short-term commercial strategy, but usually a terrible operational one.

Certain (usually early) stages of a project may be time or resource rich or permit wide-ranging changes with minimal risk (client impact, downtime, live failover requirements, carefully engineered change-overs, etc.). At these times, an experienced person might opt to utilize resources to 'over-engineer' for contemporary requirements in the knowledge that it is a strong and well- reasoned long term play, while to the less experienced, non-technical project managers or stakeholders this may seem questionable.

Ultimately, every project is different but there is a 'sliding window' of project resources (particularly time and the availability of low-risk incremental change) and requirements (expanding, shifting, contracting).

A famous quote from a famous figure on migration: _Those change-over things are really severe. Really severe problems._ \- Joseph Henry Condon, Bell Labs.[0]

Perhaps ultimately, over-engineering may be inefficient but efficient if considered in light of the alternatives: by parable, eventually including a rewrite in javascript that also reads email.

[0] [https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

<comment><USER9> Speaking of the long term.

The thing is the flavor of over-engineering JavaScript suffers from - <USER2> in frameworks/tech the project can be done without is bound to backfire at some point when (and in a ridiculously fast moving ecosystem like js we're talking 1-2 years) you can't find engineers with the skillet needed for the the "old tech"-based projects.

<comment><USER10> That's why when it comes to javascript I don't use anything but bare JS and jQuery. There is too much churn in everything else.

<comment><USER11> But then you are back to the problem where companies require new hires to know React, AngularJS, Karma, Mocha, NodeJS, etc..

</comment></comment></comment></comment><comment><USER12> I mainly disagree with the article.

Most over-engineered monstruosities I've seen in my career don't come from engineers trying to uber-optimize their solutions to a sick level, but from noob/unexperienced/dumb programmers trying to get something done.

Things like: methods with just one line of code (to call another method), classes that seem to be there just to satisfy some dubious OOP pattern, too many levels of error handling which can be simplified by just removing them and catch the exception in a single place of the program (at least in exception-based languages), too much 'public' elements in a class (justified by the programmer thinking: "just in case" someone needs to access them in the future), excessive interface use due to the (clueless)need of pedantic levels of unit testing, NIH-retards creating frameworks/ORMs/libraries for every single component their software needs (I even saw once a tech lead that replaced all uses of hashtables in the company by his own implementation which, hey, let you look for keys in a case-insensitive way!), choosing low- level languages to implement non-performance-critical software, and a big etcetera.

<comment><USER13> What you describe is not really over-engineering, at least not according to the definitions he quotes. I would just call it bad engineering instead.

<comment><USER12> Thing is, in my book, bad engineers are the ones that cannot get anything done (or barely do) because they are not talented/intelligent enough. These are harmless.

But what about the ones that get things done (at least their managers perceive so) but creating these enormous turds? They think they have a clue, but are just barely starting to scratch the surface, and they can harm any project a lot. For me, overengineering is not excessive optimization or quality, but excessive unnecessary complexity (when there could be an alternative, much simpler, implementation, which still complies with the requirements imposed).

<comment><USER14> > _For me, overengineering is [...] excessive unnecessary complexity (when > there could be an alternative, much simpler, implementation, which still > complies with the requirements imposed)._

I think the article relates to that though. I agree there are cases in which the complexity of objectively uneeded and will never be useful. (Reinventing the wheel, bad design, the aforementioned misapplied OOP principles and unit boundaries) but what the article stresses IMO is that it's not always easy to see if the simple implementation will comply with the requirements in the future as well. Some complexity could be justified if the speculation on the future is backed by facts.

</comment></comment></comment></comment><comment><USER15> My take away from this is you need to ask 'why' as often as 'what' and 'how' when developing software.

In my experience many software developers completely fail to challenge the 'why' of what they're being asked to do, and jump right to design/coding.

To be fair though, not all software developers work in an environment where they can, or feel they can, ask or challenge the 'why', but the software will only benefit if they do.

<comment><USER16> Why? is also how you resolve the XY problem[1], and asking it five times[2] is the basis of a root cause analysis, and as any parent will tell you[3] is part of raising children, and is also what you should seek to put into a commit message[4].

Why? is almost always a good question to ask.

1\. [http://meta.stackexchange.com/questions/66377/what-is-the- xy...](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem)

2\. [https://en.m.wikipedia.org/wiki/5_Whys](https://en.m.wikipedia.org/wiki/5_Whys)

3\. [https://m.youtube.com/watch?v=sahSAMj8OIY](https://m.youtube.com/watch?v=sahSAMj8OIY)

4\. [https://github.com/erlang/otp/wiki/writing-good-commit- messa...](https://github.com/erlang/otp/wiki/writing-good-commit-messages)

</comment></comment><comment><USER17> Ultimately, software design is a prediction of the future. You make those parts flexible where you will need it. You make other parts simple and opinionated where you need no flexibility. Like all predictions we are often wrong, which leads to either over-engineering or lack of features.

<comment><USER18> And it is incredibly hard to predict the future. So I just try to engineer things forcefully for only today's needs. And instead of future-proofing, I try to make it easily comprehendible. Make their intentions as explicit as possible. Comprehension trumps everything. Because before we can actually change code by typing it in, we need to be able to hold it in our head and mend it there. And if you can clearly see in your mind's eye what is currently there, you can see what it can become.

The above applies only when we have to 'predict' the future. Oftentimes we know the future already - there is going to be ton of traffic, we are going to need an API for this use case, we are actually going to stay in business etc.

<comment><USER17> > ton of traffic

This comes with assumptions. Depending on the magnitude of the traffic you need very different architectures. For example, see Pokemon Go [https://cloudplatform.googleblog.com/2016/09/bringing- Pokemo...](https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO- to-life-on-Google-Cloud.html)

> an API

How flexible should the API be? For example, do you need multiple representations (JSON, YAML, XML, etc)? Maybe it makes sense to build it representation-agnostic, but maybe it is over engineering.

<comment><USER19> This is true, but unless you understand the problem then (which you might not since not all of us work at 50x expected load) then how do you architect it properly while also not wasting time?

</comment></comment></comment></comment><comment><USER20> The year was 1991. My friend and I were partying and playing darts. 301, to be precise. At a certain point, I noted a subtraction error in my friend's score. I pointed it out so we checked everything and found I made some subtraction errors too. We were pretty wasted so this was no surprise.

I had a computer in the garage on my workbench. So I decided to solve this problem by writing some code. About an hour and some number of shots later, bullshitting with my friend the whole time, I had a working scoreboard program.

We continued playing darts. We were both amused that even though I was too wasted to subtract, I could still write code.

We probably should have just switched to Cricket.

<comment><USER21> how do you know your program was correct?

<comment><USER20> That's a fair question. Once my ability to subtract was restored (after a nasty hangover) I checked my work.

</comment></comment></comment><comment><USER22> The bottom line is that whether something is "over-engineered" or not can mostly only be confirmed in hindsight.

With experience and instinct, some people are successful more often than not in predicting what level of engineering is sufficient, and they go on to become great engineers and leaders. But I am not wholly sure if this is more skill or more luck, though I am sure there is some skill.

With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount of flexibility you need. When designing a common utility or infrastructure piece to be used by everyone in a large company, it is much less obvious. But I think the hardest layer is the mid-tier, which has to deal with the backend and the frontend, and support all kinds of changes and pluggability.

<comment><USER23> Not fearing change and being able to handle change is the skill required; and it can be learned from experience. An over-engineer will attempt to build a system that is too flexible and too complicated in order to mitigate all possible changes. Similarly, an under-engineered project will become of patchwork of impossible to maintain code when the changes roll in.

The skill is knowing how to evolve a project -- create new abstractions and layers -- in the face of change. To fundamentally alter the product and keep it working all at the same time.

If you under-engineer a project and you don't know how to do this eventually you'll be faced with the dreaded re-write. Throughout history how many companies and products have failed because of that. If you over-engineer you can suffer with a huge amount weight you don't need. And even then you still might get it wrong and be stuck with an architecture that doesn't work given new requirements -- which might require an even more difficult re-write.

So many engineers can't bring themselves to remove code or change their architecture; so they try and get it right the first time.

<comment><USER24> > Not fearing change, being able to handle change is the skill required

Agree x1000, I'm currently dealing with a situation stemming from this sort of thing (not being able to handle change, in software design, and philosophically with the architecture).

I also keep using the term "evolve" with respects to how to develop a good codebase. You can use design pressure to drive abstraction and logical components of a codebase. If you try to figure all that out from the start, you're going to have a bad time.

</comment></comment></comment><comment><USER25> > Over-Engineering is when someone decides to build more than what is really > necessary based on speculation

This is so wrong, in the context of software at least.

Over-engineered software has layers of abstraction that add nothing to the function or form of the product the costumer sees - it is over-engineering for the sake of ideological notions about design patterns etc.

As for functionality delivered to the client, software very, very rarely gets over-engineered - in reality it almost always gets delivered late and with core features still in development. The idea that there is all this software being delivered on time that not only meets 100% of all the original requirements with exacting quality and perfection, but is somehow delivering in gross excess to the point of giving customers more than they need is pure fiction.

<comment><USER26> I don't remember who it was. Might have been Michael Feathers, might have been Jeff Atwood, could have even been Slava Pestov.

One of them said words to the effect, "people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all." Make a decision. If it's wrong, own it. Develop OTHER coping mechanisms for being wrong. It's good for the ego, probably good for the soul.

The fights I have gotten into with myopic people over the years have largely come down to them putting a bunch of energy into what should have been reversible decisions, and treating irreversible decisions in a cavalier manner (eg, trying to 'get it over with').

Learn to tell the difference. Be bold with the reversible ones. Put off the irreversible ones if you actually can - but know that deciding to do nothing IS often a decision. Like deciding to add security or localization 'later'.

<comment><USER27> _" people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all."_

This goes for refactoring and TDD too.

<comment><USER28> how does that go for refactoring? when I refactor code I'm typically _making_ a decision that we have now pinned down the functionality of the code, and we are going to make the structure reflect that functionality clearly and directly while stripping off incidental complexity that came from exploring the design space.

</comment></comment></comment></comment><comment><USER29> I agree this may be subjective, but aren't we crossing the line when the 'how' becomes more important than the 'what' (i.e. the purpose of the code?)

Following this principle code example 2 (i.e. Javascript after deduplication) would be the sweet spot. It fulfills the requirements without in the most obvious way, at a good level of abstraction (the requirements did not make any of the three pictures specific -- defining a separate function for each actually goes beyond the requirements, while obscuring the higher-level goal).

All of the subsequent examples focus on using the features of the platform rather than clearly showing the purpose of the code, i.e. unnecessarily obfuscate it.

<comment><USER30> There is a good argument for using $('.image').on('click', clickImage); instead of attaching three click handlers clickImage[ABC] and hardcoding those in HTML, which probably explains why jQuery is so popular.

OTOH I agree that using jQuery for animation doesn't add anything, particularly now that CSS Animation is omnipresent. My initial though on the problem was "Can I do this in pure CSS?", not to go to javascript. And since it turns out you can't, the logical next question is why the desired behavior is actually desired, instead of e.g. just making the image a thumbnail and a clickable link to the full-size image. So really the entire question is an example of overengineering, requiring an absurd amount of technology for a feature you aren't even sure you want.

</comment></comment><comment><USER31> The real downside of over-engineering is that time expenditure is non- refundable. If you build a lightweight v1, you still have the option to invest additional time into something more "robust". If you choose the opposite, you don't have the option to get your time back by making the product less engineered.

Even worse, if your under engineered product is causing problems, you'll almost certainly notice it (rather quickly too). If you over engineer, you may never realize it.

<comment><USER32> Nope, for example if an application is designed without dependency injection because it is more "lightweight" it is a pain to introduce it later. If you designed it from the start to have clear dependencies and with an IOC container then you'll have a much easier time in changing it when there are new requirements. As you can see the boundary between good engineering and over engineering is pretty thin. And it obviously depends from the context. In a toy application probably you can survive without a container. In a real world project you are going to kill yourself without it (been there, seen that).

<comment><USER33> Yes but dependency injection only makes sense at a certain scale. I've yet to see it provide more than it cost.

<comment><USER34> I don't see this.

Designing for dependency injection is mostly about passing objects around as a parameters instead of using globals / singletons.

It's in big code bases where the tempatation to use a singleton is greatest, because no one wants to refactor all the function signatures to add the extra parameter.

<comment><USER35> Making every part of your system an injected thing can lead to massive configuration points where there is only one possible choice for much of what is configured. That is annoying and I fail to see how it really helps extensibility.

Oddly, I think the problem is often lack of a global namespace. Consider how you pull in the "parseFoo" method. In languages with a global namespace, you just use it. You can put a declaration saying the method has to exist, but no need to import it from anywhere. That is a build time concern, not a write time one.

Even better, changing the implementation does not require changing the user site, at all.

Namespaced languages have to use factories and abstract factories to get the same flexibility. (Or dependency injection.) I don't even think they're bad ideas, just find it interesting how much effort it takes to change which method I'm actually calling.

<comment><USER34> I agree with you about fractories often being stupid replacements for free- functions. I am thinking of more dynamic things: e.g. a handle to a network connection should be passed around instead of singletoned.

But even if dependency injection has all the costs you claim for it. Those costs are at their smallest when the system is small. So I still say xypud is wrong: you should do injection by default and when it gets too cumbersome _then_ you think about how to streamline the interfaces.

<comment><USER35> To be honest...I have not thought hard on this. I expected my post to get down voted, as I figured i was taking a frowned upon view. To be more fair, I suspect I am wrong.

In practice, I agree with your point. I'd rather do some small costs up front. I'm curious to explore the designs more. I think in systems where you have independent programs working together, a lot of this solves itself. The trend today is to make things one big program. (Not a new trend.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Why do we never talk about how this over-engineering stuff relates to skill development? It's the same, no matter if you look at soccer stars, chess, or programming.

In the beginning people are clueless and just try to make things change and take a horrible amount of time for it. Then they start to develop some patterns. Then they see patterns from other people and choose one as their one true hammer that will hammer all the nails. Then he spents an awful time arguing why X and Y are nails. Then he sees that not all methods apply all the time and starts to balance them with each other. And finally if he gets that far, he will start to develop his real own, efficient methods.

So where is the over-engineer in this? Not in the psychopath section but in the hammer-and-nail section. He developed far enough to be effecient in some ways but still waists quite some time on trying to make all the problems to apply to his solution. That's normal. That's also about the skill level that you SHOULD have when you leave a university type of education. In soccer that's the point where the usual children club stuff ends and they start to compete in serious competitions, maybe one age level below the one that gets public attention. You want to put people on this skill level against real tasks to realise that not everything is a nail.

So instead of always blaming people for being in this level we should appreciate it. Our university education seems to work for that kind of job quite well. And then we should continue to put these people in the right environment to develop further and provide value to their teams despite the things that they still lack.

</comment><comment><USER37> I'm trying to think of examples of overengineering in software and am having trouble from my own experience and extensive reading.

I can think of languages like C++ that facilitate what I would use a more derogatory term for like autoerotica. The site's example, taking Javascript seriously, almost always falls into this category.

In something like an automobile, using boxed steel everywhere would make the thing sturdy as hell at the expense of fuel economy and less objective things like aesthetics. A bridge design might be too expensive, or a material too heavy to facilitate the architectural vision. Etc.

In software this term is used where the software is actually under-engineered, like a shoddy deployment without any consideration of consequences. Technology like a message queue or distributed database are the victims of poor understanding or oversold claim. Almost always the real problem is clueless management and a symptom of fad driven architecture.

So going back to the materials example.. What software wouldn't benefit from end to end back pressure? Circuit breaker fault management? Memory safety? Formal proof? None of these things should have any bearing on the user, and there are a lot of companies could afford to figure out how to make one or more of these things have minimal effect on front side of SDLC with very positive effects on the long tail. Software is almost to fluid and inexpensive to be over-engineered.

<comment><USER38> In the cases I've encountered it, the term over-engineering in the context of software development is more often used to refer to building in allowances for future functionality rather than for making the software more robust. Although I have seen the latter as well - for example massively increasing the complexity of some part of a distributed system to eke out a theoretical eight 9 of availability.

The concept of over-engineering has been co-opted more recently by Agile zealots as a major bogeyman to the point where I've seen people trot it out to argue against structuring code to account for needs that are several weeks out because "It's not in THIS sprint! YAGNI!", with the predictable result that several weeks later it creates more work to restructure the code and when invariably there isn't time for that, leaves a worse architecture in the long- run as the needed functionality is bolted on.

<comment><USER34> In my experience YAGNI-abuse happens when people apply it at the wrong level.

For example, people might ignore some rule of the architecture in a rush to produce some feature. This sounds pragmatic: the feature worked, so that archtectural rule must be overengineering right?

Then you ask why this particular feature was needed _now_ at this point the project timeline, and why we had to throw aways fripperies like error detection to get it. Then I rarely hear clear answers.

</comment></comment></comment><comment><USER39> Over-engineering just means implementing something that is more advanced/complex than what was needed to get the job done (in the short term).

It's not necessarily a bad thing in a technological sense, but it's bad for business.

If people can build an extremely powerful, complex system which works well and is stable, then that's great.

Some engineers will stay away from any system which they regard as 'complex' or which doesn't strictly adhere to their technical philosophies about simplicity.

Personally, I think that if enough engineers invest their energy into building a highly complex system, I think eventually they can make it work.

You can just look at operating systems; they are extremely complex but so much human effort has been invested in them that they have become quite stable and have become essential to the functioning of our society.

This is how I feel about newer systems like Docker and Kubernetes - I think that together, they are extremely complex. When Docker started out, I thought it was crazy, I didn't see the utility value; but enough fools got involved that it eventually grew into something meaningful. I think that the offerings we have now with Docker, Kubernetes, Swarm, Mesos, etc... have become extremely compelling.

I think often it's regarded badly in engineering when you have a single component that does a lot of different things (often, that's what people often call over-engineering) - But look at the general-purpose CPU; we didn't need to invent it; people could have been satisfied with building specialized electronics for every kind of machine that just did one job well (no programming needed) but this would have slowed down innovation (because manufacturing circuit boards is expensive and time consuming).

Making generic components that do a lot of different things CAN be extremely useful when you look at the big, long-term picture. It just has to be done well and needs to be given the time to stabilize.

</comment><comment><USER40> An over-engineered system is a system where the complexity of the requirements is not proportional to the complexity of the solution.

The part that is counter-intuitive, is that a rather simple idea can sometimes have very complex requirements.

<comment><AUTHOR> Idea: As a writer, I want a platform to write a story that allows me to focus on the content instead of the formatting

Solution 1: Build the platform using JavaScript. Do user research to come up with the best design. Hire a marketing team to receive a lot of attention and consecutively feedback on the platform. Hire data scientists to analyze the site traffic and decide which feature to add or not... in the end, through small cycles of feedback, continuously improve the platform and spend millions of dollars to come up with something very good after some time

Solution 2: Use medium.com, because sometimes a rather complex idea can have a very simple solution.

<comment><USER40> Solution 1 is a committed solution.

Solution 2 is an uncommitted solution.

You can always go from 2 to 1 at a low cost.

</comment></comment></comment><comment><USER41> For motorists, over-engineering is how the engines worth buying are those which are expected to last 10 years even though they are only warranted for five years.

It's the way many bridges having a posted weight limit of 10tons can handle a 12ton truck without incident.

If you go to all the trouble of actually engineering something to begin with, might as well include some effort into making it stand the test of time while performing beyond expectations. One of the most fundamental features of true engineering is a "margin of safety".

Traditionally this is what increases the chances of your product having that most useful feature; "worth buying".

</comment><comment><USER42> The specs are the part I found most interesting. 1) First the specs say 3 images, then they say 2. if you are dealing with a manager that can change the specs like that you might want to over engineer just a bit to cover 'arbitrary number of images'. yes I know this is probable just an error by the writer of the article, but it demonstrates something that happens in the wild. 2) Communication is the missing piece in this story. when a developer is given a task they should ask questions about future requirements. "Is it always going to be 3 images?", "will the images always grow by the same ratio?" and so on. the way to not solve imaginary problems is to talk with the stakeholders.

<comment><AUTHOR> Good catch! That was a typo. And very good remarks on how to relate that to the real world, definitely agree with that!

(Btw I have fixed it :D)

</comment></comment><comment><USER43> I think 'over-engineering' is too broadly used. Clearly some solutions are over-engineering, but most are built by skilled and experienced engineers who know that requirements change / evolve. In this (common) scenario, not predicting it - and creating the necessary 'over-engineered' solution - <USER3> lead to a failed project. Alternatively, predicting the wrong thing to 'over- engineer' is equally problematic.

Without these gambles, the project will often fail too.

It's a really rather difficult problem.

</comment><comment><USER44> Managers are always suspicious that engineers are doing the wrong things. Living under this cloud is just part of being an engineer.

Granted, my experience is more with hardware than with software, but getting a design "just right" can be costly in analysis and testing, and there's a palpable concern that if you aim low rather than high, a substandard product will get pushed out the door. It can be exponentially more costly to correct a weak design late in a project than to over-design it early: Subsystems and schedules become more inter-dependent, the closer you get to launch.

I can give you a good design in six months, or a bad design in twelve. ;-)

</comment><comment><USER45> The take home point I had from this article was that the requirements of will determine what you need to build. If this is a startup with minimal resources, the requirement is that you need to create something fast to see if you can solve a problem. At that point you might take those learnings, throw away the code and build a more extensible and robust version 2. The problem I often see is that people over engineer based on a set of requirements which assumes that the problem you are trying to solve is the right problem to solve.

</comment><comment><USER46> In my experience, over-engineering is driven by a fear of refactoring. For whatever reason, refactoring is a process that is both culturally and technically undernourished.

</comment><comment><USER47> Two take-aways for me:

1\. Make sure engineers are engrossed in the business case. This sets proper scope.

2\. Don't generalize something ahead of time, only _after_ you do the same thing twice. The architecture should support easy refactoring, and there should be certain discipline about actually _doing_ the refactoring the second time around.

There are many challenges to overcome with both of these, but it will be worth it.

</comment><comment><USER48> In my experience we live in an era of near-insurmountable technical debt, and gratuitous complexity as the quick-and-dirty solution is always slap on another leaky abstraction.

Under-engineering is the problem for anything that's supposed to last.

</comment><comment><USER49> My definition of Over engineerkng is that you try to cover many edge cases which are not belong to the current system scope, or you try to concern system performance improvement cases which are uncertain.

</comment><comment><USER50> Let me tell you a story about companies that often confuse thinking about the best solution with over-engineering...

You get hired by this startup with great ideas. They have really hit their niche nicely and are getting more and more customers. You build a great throwaway prototype and customers and the mighty CEO love it. You ask when you are going to rebuild the prototype, since it's a bit of a mess... The hipster CTO says that there is no need, that you are the greatest dev ever and that he will get a tattoo with your name.

The first change request comes in. Easy. It's still straight-forward to make some quick and dirty changes here and there. You call it a day and your hipster CTO throws a party to celebrate the amazing job.

After change request 10, you feel like slowing down drastically. The mental model you could fit in your brain until now, is too complex. You can't touch all the involved parts of your application anymore or it would cost you a lot of time. You get away with some if/else statements to fix the edge cases. You feel happy again, you did it! You call it a day, your hipster CTO pats your back and gives out some beers.

After change request 20, the system is a mess. Different layers of the application talk directly to each other, thus creating painful coupling. Your abstractions are either non-existent or all in the wrong places. You have no CI, because that would have been over-engineering the test suite. Your local tests take half an hour, because making them run in parallel would have been over-engineering. The time for documenting the project was spent hunting quirks somewhere in the darkest places of your application. You don't even try to touch some of the code you wrote just a couple of months ago. "There be dragons" is, next to "TODO", the most used comment you find in the codebase.

So after many days, the job isn't done yet. The mighty CEO gets nervous and starts running all over the place, giving you some "leadership". He says that there is a deadline not to be missed or the universe will collapse. The hipster CTO even has to skip his yoga-classes to meet the deadline. After many extra hours and even more energy drinks, you get the change request done. The hipster CTO just smiles at you, but no beer this time.

There is 10 new bugs but you don't know about them yet. Soon you will, because people will start complaining about that last change you did and the bugs you introduced. By this time, you are sick and tired of it all. You hate yourself. You feel guilty. Problem is, you don't even have the time to think about how tired you are. Request 30 is going to arrive soon...

But hey!, don't forget that you HAD TO ship it quick, not think about solving the problem! Abstractions? Over-engineering! Designing for resilience? Over- engineering! Small, independent services? Over-engineering! Staging system? Over-engineering! All these thoughts come to your mind everytime. Yet, you are so tired, you fall asleep and try to forget it all...

WAKE UP! THERE IS A BUG IN PRODUCTION!!!

You need to rush. In the middle of the night, your messy apartment gets illuminated by the blueish light of your laptop. You don't even care anymore.

The End

\---

Appendix

By change request 40, your soul committed suicide.

By change request 50, the company was spending 80% of their time doing bug fixes and keeping their self-build house of cards running.

By change request 60, there was this tiny competitor who gathered together a nice little team of skilled and motivated engineers. The CTO would give them time to think about how to solve the problems best. Soon they entered the market at an amazing pace. All competition went out of business. You lost your job. You have no motivation. You feel lonely.

By change request 70, which never actually happened, that tiny competitor sees you as a valuable asset to their company. Since they are growing, they need people like you, with experience and skills. You still feel like the worst developer ever, but you take the job. People respect you. The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. People share their ideas and with each iteration they make it better.

Finally, after all, you are happy again...

<comment><USER51> > The software was designed following best practices. It is stable, people > iterate quick. You can take your time to think about the best solution.

Except that the messy project you were working on before sounded like a one man project. And at every new change request you delivered, working by yourself, a pretty big chunk of value.

Now, in the nicely engineered project, you work in a team. The team is iterating in sprints that require a number of developers two or more weeks of work to deliver the tiniest feature. Yes, iteration is quick, but it doesn't really deliver much value. Every time the new CEO requests something even slightly different from the exact functionality that was developed so far, the project architect's answer is that this will not fit in the current set of features, and it might be possible, if ever, after another series of sprints that will take multiple months to complete.

And the funny thing is that, while in your one man project you were considered a lone cowboy working on a relatively simple system, the architect of the current project (that delivers more or less the same functionalities but requires 5 or 6 times the time and resources to maintain) is considered a demi-god "because the project is so complex". Because of course the CEO measures the complexity of the project not but what it delivers, but by the amount of resources consumed by it. And while the CEO of the previous company was annoyed when a new feature required more than a week to implement all by yourself, now whenever the new architect says "we need more resources for that", this actually _increases_ his power and consideration in the company, as it is taken as a sign of the complexity of the project.

</comment></comment><comment><USER52> > more robust or complicated

In my experience (mostly in networks) these are two different things with a negative correlation between them.

</comment><comment><USER53> And within all of that nothing is included in the code to handle double clicks or event bubbling.

</comment><comment><USER54> Are the DC-3, B-52 or W124 overengineered? I fear the gentleman is misusing the term.

</comment><comment><USER55> I tend to associate the term "over engineering" as a positive term..

One can't lump safety in with poor engineering.

seems to me the article is talking about something akin to "wrong engineering"

</comment><comment><USER56> Over-engineering is a tough thing to discuss and there's never going to be a suitable answer anyone agrees upon. It is also a huge topic with a scope far beyond this textbox or a medium article.

Anyway, among many of the big issues here are so many things are contextual - the problem domain, stakeholders, programmer abilities, business climate, etc. It's been my experience that you cannot apply judgement to a solution without understanding as many of the variables involved as possible. Shifting these variables even slightly can change everything.

For example, say I build a feature A at company Y and then I change jobs next week and to company Z which is much smaller. Company Z wants the same feature I just built at company X, but of course I can't steal it outright. Building the same thing at company Z requires different engineering decisions, given the different climate and probably different development team, programming language, and so on hypothetically. Even if I could just copy the solution, at company Y it might be perfect, while at company Z it might be considered over- engineered. It's a combination of both objective and subjective judgements.

As for the concrete implementations of features, I often am driven crazy by both over and under engineering. I worked with several people in positions of power above or horizontally to me that would routinely shoot down many well- engineered features and implementations by other people because they were, "Too complicated." I began to realize this was often shorthand in most cases for, "I know nothing about this, my ego or political stance is threatened, I lack talent, and/or I am simply a moron." Of course I also hit plenty of actually over-engineered things that were indeed exactly this, but in many of these cases it was obvious. Where it is less clear is anything of decent scope, challenge, subjectivity, or other hard to quantify measure. I think people can look at something like the FizzBuzz and see that the parody versions using OO 10 design patterns with abstract factories are obviously over-engineered, while it gets much harder in the context of a big project.

And this leads to another problem. Complexity is not over-engineering, nor vice-versa always. Nor is scope, or code size, or any of these related concepts that come to mind. A very small amount of code can be incredibly complex, a large amount of code can be simple, and so on. Either can be over or under engineered. Just look at math - some of the most useful tools are very difficult to understand, while others are incredibly simple with tons of layers, nuances, and so on. Programming is not that much different in this regard. We've all seen things done in a tiny amount of code we would have never thought of and maybe can't even understand. Likewise, we've encountered huge amount of code that someone complains about but is written clearly, thoughtfully, and cleanly. These's a good related talk on some of these ideas by Rich Hickey if I recall.

Another issue is that it is hard to quantify both knowing what and when justifies substantial engineering efforts. As I mentioned, context plays a big part, as does intuition and experience (in relation to ability, not just pure years). These are all nearly impossible to quantify, and yet must play a large role in cases where large engineering decision making. A lot of people see things they don't understand or are new to them and just throw out the over- engineered card. Likewise, a lot of people love pulling out their favorite tool (ex: SQL, Framework of choice) and try to use it as a golden hammer. Anything else is "over-engineered." These things can lead to over-engineering or at the very least, poor engineering.

Over-engineering is also something that is relative. It is really hard sometimes to work with someone else and to get them to understand especially those hard to quantify things such as intuition. Programming can also often highly be about ego and ownership. People will not hesitate to point at something not written by them as over-engineered because it was not done how they would do it.

Game programming for me again comes to mind as an area where this is a constant pain. The inexperienced game programmer will both under and over engineer things like you've never seen. First, they'll try to use their favorite language to write a game. They'll then do things when they learn a technique like OO programming and try to apply it everywhere, to everything. "A monster? Obviously I should make a monster base class, then subclass this for an Orc, then subclass it again for an Elite Orc." Everything must be designed around the tools they know instead of the problem. The minute this person does enough in their career to get any real authority or a real job, they take this unchecked mentality and try to impose it on the people around them. I see the same thing in web application and desktop programming. Someone learns lambdas, functors, currying, design patterns, IOC, monads, etc. and they must apply them to any situation that triggers this recognition. The "engineering" then comes from the solution and tools, perhaps the XY problem in many cases. Usually these people also fail to consider the aforementioned contextual concerns.

I know in game programming this happened often where some programmer would come in and replace some lengthy looking code that made heavy use of arrays and manual for loops. They'd then go in and replace it all with vectors, iterators, and all kinds of heavier stuff. They never considered that the code was engineered that way for performance or for portability or backward compatibility or some other reason. Moreover, they didn't actually know that the seemingly "simpler" solution was actually making things as a whole more difficult by pushing out these concerns to be fixed or handled elsewhere (ex: making up performance somewhere else).

On a personal note, I am often annoyed by the over-engineered finger pointing. There are so many things like XML messes and 200 steps to setup something for a simple purpose that are easy enough to agree on as over-engineered. Most of these come down to asking yourself, "What problem am I trying to solve" and perhaps repeating those steps aloud. If you feel ridiculous saying them, especially to another person, something might be wrong. But if it turns out that the problem you are trying to solve really does require something that is not a sound-bite, the problem explanation will also often have to be long and cannot be skirted around without ignoring the problem.

Too often I see things in this industry thrown out there to "fail hard," to be an MVP, to test the market, to disrupt, to fill a gap. That's all fine, but make sure you are solving the problem and not creating new ones like security, performance, misleading people, defrauding investors, or worse because you thought engineering a proper solution is too hard or takes too long. Find the sweet spot and make informed decisions. I recommend another talk about Rich Hickey (sorry two by the same person, just memorable talks) about Hammock- driven development and thinking before acting. If more people did that, it could swing either way and maybe we would have less short-term "stuff" but better long-term solutions, less over-engineered messes, and things that actually are worth building on top of as bases. As it stands now, this industry is littered with poorly engineered solutions we were stuck with because of both over and under engineering.

</comment><comment><USER57> > A famous comic using the attempt of building a tree as the analogy of what > is wrong in each part of the traditional development lifecycle

The project in the comic actually appears to be building a _tree swing_. I'm sure this was just an oversight on the author's part but if anything it reinforces the point the comic is making.

<comment><AUTHOR> Author here. You are right, I did not know the name of the thing because English is not my primary language. Thanks for teaching me that, I have edited the picture caption to show the correct description of the image. Thanks!

<comment><USER58> I've never heard of a "tree swing" before, or any swing named after the thing it's hanging from.

I would call the thing in the last panel a "tire swing." (Native English speaker, FWIW.)

<comment><USER57> Yeah, it's worth noting that "tree swing" isn't a common idiom; I only meant a swing that's set up on a tree. I just didn't want to call it a "tire swing" though because it only took that form in one panel. Maybe "rope swing" would be the best name for it?

<comment><USER59> It's just a swing.

<comment><USER60> So you're saying the term 'tree swing' is overengineered? ;)

</comment></comment></comment></comment></comment></comment><comment><USER61> This engaging article on overengineering is 2.7 MB in size, and takes over a hundred web requests to render.

<comment><USER62> So? The author didn't 'engineer' medium in order to distribute this post. Maybe he was already familiar with the site, or maybe he finds it the easiest to use?

<comment><USER63> Oh, so there is a good reason to accept over engineering.

<comment><USER64> This argument makes no sense?

<comment><USER65> The argument makes perfect sense. Nobody can use the theoretical swiss army knife pictured in the article - it's too wide, and ridiculous.

In the graphicon of over-engineering taking over users and enveloping them, pushing design out of the way, it implies that the result is hostile to users, and pushes design out of the way.

But where we read this is an example of the person selecting the "knife" in question out of every single blogging platform on the planet. So, the swiss army knife pictured is inaccurate, it's a straw man. Secondly, the author clearly finds the design appropriate enough to use, and a great match for their user stories.

So whereas _the_ central thesis in the article says:

> "small, elegant, and successful systems tend to be plagued with feature > creep due to inflated expectations".

The author is _not_ using a "small, elegant, succcessful system".

Perhaps the swiss army knife pictured is the best knife on the planet, and not one of the worst. This fundamentally undercuts the point the author is making.

<comment><USER64> I believe the comment I was replying to was saying one should not use Medium because it is an "over-engineered blogging platform." I was not arguing for creating or using theoretical swiss army knifes.</comment></comment></comment></comment></comment></comment>


Too good to be true (the overnight millionaire scam) - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2008/11/too-good-to-be.html <comment><USER2> I find it interesting that the word "millionaire" still has the emotional allure it had in the 1920s, despite having deflated so drastically that "billionaire" would now be a more correct equivalent.

<comment><USER3> Agree - several of my friends are millionaires, but I don't consider them ultrarich. Neither do they sonsider themselves ultrarich.

<comment><USER4> Ultrarich is a dumb word and means nothing. Sort of like a college kid saying everything is 'epic'. Ultrakill means more to me than ultrarich, at least I can define it.

</comment></comment></comment><comment><USER5> So the point of this article is "Don't listen to late night infomercials promising overnight wealth?" Is that anything other than obvious? In fact isn't there an obvious corollary involving not reading Seth Godin's blog posts?

</comment><comment><USER6> And what part of this post isn't common sense?

</comment><comment><USER7> I hope that most of us already realize this.</comment>


100% CPU usage in Chrome 67 - <AUTHOR> https://bugs.chromium.org/p/chromium/issues/detail?id=848210 <comment><USER2> Glad I'm not the only one, I noticed what felt like the same thing.

Mildly funny: [http://instantshare.win/4l78fj71b0j5.png](http://instantshare.win/4l78fj71b0j5.png).

</comment><comment><USER3> HiddenChrome: Secret Settings & Tools (chrome://flags/) [https://chrome.google.com/webstore/detail/hiddenchrome- secre...](https://chrome.google.com/webstore/detail/hiddenchrome-secret- setti/jhcdplpmjpchlfjfihdpimbakifjnnda?hl=en&)

url: (chrome://flags/)

Simple Cache for HTTP (Enabled) Throttle Expensive (Background Timers Enabled) No-State Prefetch (Enabled No-State Prefetch)

Worth A Try!

<comment><USER4> It's not worth fiddling with internal settings for this one, clearly the bug report indicates it's a known regression and it looks like a fix will be pushed out soon.</comment></comment>


Ask HN: Why are forums not populair for company collaboration - <AUTHOR> I like slack for sure but I hate it for more in depth conversations and I can't really backtrack any discussions being made at a certain point of time.<p>Some companies I worked had a forum and I loved it, why do forums get used less and are chat tools so popular? Does your company use a forum? <comment><USER2> Disclaimer: I work at Discourse, so I'm totally biased :p

We use a Discourse for:

\- Support, feature proposals/discussion, bug tracking at [https://meta.discourse.org/](https://meta.discourse.org/)

\- Commit reviews [https://review.discourse.org/](https://review.discourse.org/)

\- Shared inbox for email support

\- Company planning at an internal instance

And we see a growing need for better tools for company collaboration. It's even greater if you work on a distributed, remote team that spans dozens of timezones like us. Chat doesn't cut a discussion that can span months, years. Or when you want to actually put tough into an argument, bringing paragraphs, links, multimedia content, etc.

We have a few blog posts about it:

[https://blog.discourse.org/2018/03/how-does-team- discourse-u...](https://blog.discourse.org/2018/03/how-does-team-discourse- use-discourse/)

[https://blog.discourse.org/2018/04/effectively-using- discour...](https://blog.discourse.org/2018/04/effectively-using-discourse- together-with-group-chat/)

And a new one coming soon about teamwork.</comment>


Does Google do "research"? - <AUTHOR> http://matt-welsh.blogspot.com/2011/01/does-google-do-research.html

<comment><USER2> Reading this article confirms my tremendous respect for Google for:

1) Creating a culture where writing unit tests, fixing bugs and the like are not viewed dirty work or an overhead, something that scientists (or even engineers) are above

2) At the mean time, being a place where creation of new technology (even if not strictly related to the primary product i.e., not just information retrieval algorithms) is not viewed as "academic" or a risk to be avoided at all costs.

There are companies which do (1) well and companies that do (2) well; they have created wealth and made products I enjoy and use. Only a handful managed to do both: they changed far more than their industry.

<comment><USER3> I was spoiled as my internship January last year with Google was my first introduction to the world of corporate IT. Google as a culture really encourages engineers to follow best practices - "Testing on the Toilet"[1] was always a highlight.

As you say, the emphasis on unit tests is amazing and something not found in a lot of professional companies. When you tell someone you haven't committed your code yet because you're writing unit tests they don't tell you to hurry - it's not considered something you can rush.

Additionally some of the research that has come out of Google Research [2] is stunning and I suggest if people are interested they can keep tabs on new publications via their feed [3]. A lot of their tools and products really are pushing the boundaries of the field they're in, both in complexity and scale, so the "reports from the front line" offer a unique insight.

[1] - [http://googletesting.blogspot.com/2008/08/tott-100-and- count...](http://googletesting.blogspot.com/2008/08/tott-100-and- counting.html) [2] - <http://research.google.com/pubs/papers.html> [3] - <http://research.google.com/pubs/atom.xml>

</comment></comment><comment><USER4> The danger with integrating research as part of day-to-day development is that you might not end up with groundbreaking or disruptive innovation. The problem is that forces which are controlling day-to-day work are essentially controlled by value network of the company (social and technical resources within and between businesses) and constrained by resources, values, and processes of the company. So, there is a danger of missing inventions which will replace the current (profitable) way do doing things (i.e., start Groupon kind of business model, or Twitter, or Facebook).

However, I also 100% agree that having pure "research labs" is not effective: in many cases some great idea from research arm are just forgotten.

Clayton Christensen wrote a few books on this topic (and I am a very big fan of Clayton Christensen's work).

I would like to also mention that Google is not the only company which has this approach: it seems to me that majority of companies in Silicon Valley operate like this (I don't think Facebook has "research labs", but they do invent things).

<comment><USER5> > forces which are controlling day-to-day work are essentially controlled by > value network of the company (social and technical resources within and > between businesses) and constrained by resources, values, and processes of > the company.

Google's 20% Time could be considered "research" or R&D not constrained by business requirements. 20% Time seems like a clever way to harness engineers' downtime for work that may benefit the company.

But none of the Google engineers I've met had a 20% Time project. They said product teams (like Android) had much less flexibility for 20% Time than people working on google.com properties.

</comment></comment><comment><USER6> Two disconnected thoughts that came to mind reading this...

1\. I agree with Google's approach. Microsoft spends $10 billion a year on R&D yet I can't think of a revolutionary product they've come up with (Kinect was bought from the outside)

2\. I notice the word "patent" is never mentioned in this piece. A big reason companies like Microsoft and Intel have research labs is to patent protect themselves in the future (wasn't there an article on HN just a few days ago that mentioned Google's anemic patent portfolio?)

<comment><USER7> MS's approach to research is fundamentally different than Google's. Google's approach is about creating better Google products. Microsoft's approach (which is really Bill Gates's dream) is to advance science.

Both are good goals. But if you ask a researcher from MS how important it is to get in a future version of Windows, they may well shrug their shoulders. Their feeling is if they can advance technology then all boats rise, which is good for Microsoft.

I must say when I'm actually doing research, and not just dev work for product Version Next, I don't want to do unit tests and a whole bunch of other cruft. My code isn't meant to be shipped to customers. Its meant to test a hypothesis.

<comment><USER8> MSFT research is much more like research of great American companies of the past, Bell, AT+T etc - I'm sure this is what they were aiming for.

<comment><USER9> This is what scares me about Microsoft Research. Since Google's research adds direct value to what it's doing, it is quite unlikely to disintegrate.

<comment><USER7> I suspct if left completely up to Sinofsky or Ballmer MSR would shut down (or be substantially smaller). I think as long as Gates is alive and/or has large influence, it will be a relatively big part of MS.</comment></comment></comment></comment></comment>


Americans with Disabilities Act Rulings to Change Website Design - <AUTHOR> http://www.usatoday.com/story/news/nation/2013/07/05/moves-improve-access-to-websites-disabilities/2491051/

<comment><AUTHOR> It seems like a whole lot of website (and app) design completely ignores this segment of the population. Too many designers have forgotten the principle of "graceful degradation" such that much of the web is completely unusable for even the mildly handicapped.

I think it is quite stunning that Netflix had to be sued into including closed captioning.</comment>