In my experience, that is the heart of what is wrong with a lot of software projects: it's considered taboo to do both architecting and developing.

The theory is obvious enough, but in practice an architect that is not implementing overlooks some very significant issues. The implementer has his hands tied because 'the architect said so' and the implementer trudges on also blindly unaware of anything beyond his little island.

The best teams I've been in have had everyone participate in architecting and development, with healthy amounts of communication.

The thing about construction projects is that they are simply so massive you need a horde of construction workers. In software development, we often like to *think* we are making something equally massive when in practice if we do need that many people working on it to get to the goal then it 99% of the time means we are doing something wrong in the first place. If we put hubris aside and realized that the scale isn't so grand as to require a trillion little dependencies and components, we produce good code. This doesn't mean the opposite situation of a gigantic monolithic blob is good, but there is a reasonable middle ground.

My point was that in MS world, you don't have a compiler until you get the SDK (which most people don't even know exists), and most think you only get a compiler through visual studio, whereas in linux it is commonly already there or a 'yum install gcc' or 'apt-get install gcc' away. A *whole* lot of people assume visual studio is a hard requirement to develop with microsoft first-party toolchain and as such you end up with project files for really stupid crap.

Yes, if a project gets to be large, then you need careful process. There are a few flaws though:
1. A large proportion of the time, you are doing something far less complex and/or dangerous than bridge building. There are people who insist that for something akin to 'hello world' test cases must be written, everyone must use a bloated IDE, all code must be in version control managed by some project hosting site with issue tracking, wiki, code review, and continuous integration. Sure, there can be value in that stuff, but there is cost. Frequently the cost outweighs the value for simple utilities (git and test cases are generally tolerable, but venture far into mandates about IDEs and project management and it can get nasty).. One example for me was for a quick 2 or 3 line C program people might fire up visual studio, and end up with a 'project' with a lot more metadata than the application itself, when using the microsoft SDK by itself with notepad would have been just as good (in linux the 'just run gcc' can be taken for granted, in MS you don't have a compiler and most laypersons don't even realize you can get SDK without visual studio, so I used that example since I see visual studio project files for the dumbest stuff).

2. A great deal of the tools are frankly half-assed. Particularly when it comes to deploying the tools. Once deployed they work about 80% of the time, but then fall over and block progress while someone figures out why the tooling fell over. A lot of these development tools got to the point where the authors of them could use it and that was about it. One who understands every nook and cranny and can quickly recover given a stack trace doesn't feel as strongly about doing the other '1%' of work to make it easy for others to deploy and administrate.

Actually, at least for a lot of Amish this isn't the case. For example, many Amish communities will have phones. They may relegate them to emergency and/or communal space use because they don't think it's good for private family time to be disrupted by a phone call. They reject grid power but do use batteries and generators. They use LED flashlights and buggy lights rather than burning lamps in many cases. They use cash registers, alarm clocks, and even power tools to some extent.

Sure, they are a lot more reluctant about technology and they believe a lot of family and social values are threatened by wanton use of technology, but they do partake of some key technology benefits.

It's not really 'credit' in that time frame. We are talking about simple price stability. Having 30 days to pay your metered electric bill is not really credit, it's just allowing for reasonable delay on the part of the billed individual for the logistics of allocated and spending money. post-paid metered stuff works like that all the time. If post-paid really bothers you, then wait until a product announce is willing to state MSRP in BTC.

I don't think anyone can claim that bitcoin cannot have inflation. It has hyperinflation and hyperdeflation in pretty frequent intervals.

They can claim that the inflation/deflation is not within the reach of government manipulation, but it definitely does happen in very chaotic unpredictable ways. One's tinfoil hat has to be on very tight to see that as an improvement.

That's a low bar to set. If you can get a price or invoice in BTC that gives you a month to pay it off, then I'll start considering it a viable 'currency'. Accepting bitcoin with just-in-time pricing is very low risk and it's cheap for a company to do that for publicity with no downside. A company need not believe in bitcoin in all to do it. A company believes in bitcoin if it will commit to a long term price for anything it supplies or purchases.

If 'at some point' is 'when tax laws and reporting make it most effective' it is a bit different than 'at some point' being seconds after the sale, with quotes longer than 15 minutes being considered invalid.

Notably dell will announce products with MSRP in dollars, euros, pounds, etc. They will not do the same in BTC, they will instead do a just-in-time quote that is invalid about as quickly as they can get away with. There is no even vague assumption about BTC value from one hour to the next, unlike the other currencies.

But people 'save' currency and plan retirements around quantities of it and such. Value fluctuations are real and troublesome of course, but in general this works. I give a company 30,000 dollars and they will keep it in an account for some non-trivial time and report their quarterly success in terms of those figures. They will at least talk about the value of currency in a manner that assumes pretty much absolute stability over 3 months and even project their expectations for how much money they will get and spend over the next several years.

All the companies worth their salt that elect to engage in bitcoin in a way to get publicity, but none want to plan for the value of the 'currency' for more than 15 minutes. You won't see dell doing a promotional price in terms of the bitcoin value, but rather you get the price converted to bitcoin as you pay for it with a quote that is invalid 20 minutes later.

Long story short, MS has proved they can buy a large market, but cannot figure out how to make a profit after achieving that end.

xbox 360 enjoyed a very brief couple of years of profitability that waned too quick to pay for the losses suffered in the years prior. xbox one tried to cash in on some of the carefully cultivated brand value only to see a fickle market jump sides and show their really wasn't much persistent brand loyalty (a lesson that also bit Sony in the ass in PS3). It's the only way I can figure MS would offer a lower spec system at significantly higher cost, a hail mary for margins to see if they could hit the ground profitable since so many people seemed to 'love' their xbox 360.

Also, xbox did nothing to build up the 'microsoft' brand, it basically built a new brand 'xbox'. Attempts to leverage that outside of gaming have fallen flat, so they don't get any residual benefit from the business unit whatsoever.

I'm guessing xbox one will be the last venture for MS-owned gaming. I suspect they will sell the brand since it has undeniable value, but MS cannot figure out how to profit from that and so it is time for them to give up.

It's also time to give up on surface RT (I frankly thought it was a misguided attempt in the first place) and on being a hardware company in general. All surface, surface pro, and nokia did was alienate current and potential partners. Looking at the market trends it is clear that 'trying to do it the apple way' is the wrong way. Apple is the only one to even remotely make it work, and they are losing ground to Android at large. This is actually very similar to how MS surpassed Apple, through a large ecosystem of vendors competing against each other by leveraging a common arms dealer. Problem for MS is that Google monetizes the platform in a different way so the classic 'pay for your software license' model that MS is used to doesn't fly.

Or it could be a deviation that had little to no practical downside in selection since the world rarely went that weird in the past. It would explain why motion sickness is so prevelant, yet not close to universal. There may just have been very little selective pressure either way.

I think on the poison theory, if your senses are impacted, the ship has sailed on ejecting the poison.

If it was a selected-for trait, my completely unsubstantiated guess would be something about falling out of or maneuvering within trees. After all, people who get motion sick can get sick in excessively peculiar real-world motion without messing with reference points (e.g. some people do it on roller coasters without looking at the car that much, or on boats without looking at the floor).

I have high hopes that the movement won't bother me, I've never had a hint of the issues many report, though I haven't tried VR, per se.

I will say even if there is a problem for people who can stand it when it's a conventional screen but lose it at the threshold of VR, there is yet hope for FPS genre without cockpits. Imagine playing your game and the monitor having the appearance of a movie theater screen. An experience that is totally impractical in reality, but not really much of a big deal in VR. There is a lot of interest in things like VR Cinema and virtual desktop (https://developer.oculusvr.com/forums/viewtopic.php?f=29&t=8182). In both cases, the medium is still fundamentally not motion sensing or surrounding in any way, but the concept of playing with screen size, curvature, and distance freely all while not imposing any particular posture is quite appealing.

I think that's a bit of overestimation of these 'new, ultra efficient' companies. The volume of IT work has increased a lot over the past couple of decades, despite a seemingly more homogenous IT world with fewer 'newer, ultra efficient' companies (compared to the state of things in the early 90s).

In practice, the industry has just been shuffling I think. Some key specific cases see some gains or else loudly think they got gains, but there are losers too.

Some areas that were more automation friendly actually get less automated (some expensive automation features are falling out of favor in some datacenters in favor of low lost local labor). Many of these have sensibilities of 'buy a whole new server' rather than trying to fix something, meaning more volumes for their server vendors.

In the rise of 'cloud' we see a phenomenon where a lot of companies end up paying twice. They outsource their needs, but find out their IT staff actually is still needed (since the cloud providers actually don't help on as much as the stack as would be needed, and even when they do, they don't find a lot of takers). So they end up funding more headcount for their provider without getting to significantly reduce their own (which frequently means increased actual IT cost).

This is a bit on the pessimistic side of things, but these phenomenon add up to the chase for the 'magic bullet' continually driving change but not necessarily workforce reduction.

The closest thing to concrete data about that whole situation could accurately describe:
-Agency plugs in lenovo laptop with preload intact
-Agency notes that a TCP SYN packet was sent to China, but not allowed to actually get there.
-Agency says 'screw it' and bans it without further analysis

This could be nefarious or it could be checking for firmware or driver updates. There's no way to guess what really happened without details of any investigation coming to light.

Keep in mind that it was likely an activity driven by some agenda. Notably, these agencies start from a perspective of 'distrust china' and consider it their job to prevent that vendor selling into agencies. So they seek the flimsiest reason to hold up to impose a ban, which no one really objects too hard to since it's politically better to not source from China anyway. The agencies may not have detected a real threat, but they likely presume a real threat is a significant possibility that they have no way of practically detecting, so they run with this.

If there was an unambiguous backdoor seen, you bet your ass the agencies would be shouting from the rooftops. Instead, they are doing enough to keep it away from sensitive areas, but not so much to invite much scrutiny.

Finally, if China *really* wants backdoors, they don't need to actually have even slight ownership of the company. All the big companies gleefully hand over pretty much full control of their manufacturing and much of their hardware design, software, and firmware development to China anyway. The nationality of the CEO means approximately nothing in the scheme of state sponsored espionage.

The issue being that is *always* the case. In the early python 2 days, they thought the 'early' days were over. I haven't dealt with python 3 with sufficient depth to be keenly aware of any real gotchas, but the fact they decided to add back in the explicit unicode syntax is a sign that they have at least continued to indulge in flux to fix bad design decisions. In that specific case, I don't see a downside for the increased ability to have python2/3 agnostic code so I won't declare any example of breaking 3.x series code with that. It seems clear to me that the python language can't quite exercise enough restraint in their enthusiasm for their vision of improved syntax and features to walk away confident that code won't break in a couple of 3.x generations.

It's almost like a curse, the more popular and energetic a language implementation is, the more likely it is to experience some incompatible evolution.