Vad tycker ni om Windows 10?

Microsoft hade två val.

1. Gör det möjligt att skjuta upp uppdateringar hur länge som helst
2. Tvinga omstart efter en viss tid

Val ett leder till att ingen uppdaterar någonting någonsin och alla datorer på internet läcker som ett såll, virus och trojaner härjar fritt, det blir världskrig och jorden går under efter 2-3 månader.

Val två leder till att några envisa användare skjuter upp omstarten så länge det går tills dess att de blir tvingade och blir sen förbannade på hur Windows 10 Home är designat. Världen är säker, människorasen överlever och det blir fred på jorden.

*OBS* en smula överdrivet resonemang

Skickades från m.sweclockers.com

Min lista var dock aldrig riktad mot Svenssons, den var skriven för Sweclockers forummedlemmar på en nivå som de flesta här kan ta till sig.

Helt rätt. En anekdot: Jag tycker att startmenyn är en bra grej och att det är skitbra att man slipper helskärm. Min fru däremot, det första hon gjorde på sin laptop var att se till att startmenyn blev fullskärm, när hon uppgraderade till 10.
Hon lär göra samma sak på sin stationära

Du behöver inte köpa en ny licens utan tian stöder uppgradering till Pro och det kostar inte 1500.

Det där är väl inte riktigt Home-saker dock.

Nja, någon gång måste man tvinga en omstart om användaren vägrar och man har ett antal dagar på sig vilket borde räcka för att spara det man håller på med. Sen är det självklart att omstarten stänger programmen "försiktigt" och inte bara dödar dem. Datorer som inte får startas om bör inte köra Home.

Yes, det är det man får betala för att ha möjligheten att göra ens dator osäkrare (och en massa annat förstås)... Och, inte 1500 utan mer 1000.

Är du inne och stänger av services flera gånger om dagen så låter det som om du inte riktigt vet vad du håller på med, alternativt att du gör något väldigt avancerat. Oavsett så är det inget en normalanvändare gör särskilt ofta om alls, och då är det ganska naturligt att inte ha den inställningen i de enkla inställningarna. Om du behöver ändra sånt flera gånger om dagen så borde det inte ta så lång tid att lära dig att du kommer åt administrationsinställningarna direkt från ett högerklick på start. EDIT: Sorry, man kommer inte åt dem direkt, men kontrollpanelen och därifrån är det ett klick.

Men då är det ju Pro man ska ha liksom. Pro är inte bara för proffs eller företag utan det är för de som behöver mer än home. För att ta till med en billiknelse så är det inte som en Volvo-lastbil mot en Volvo-kombi utan mer som en småbil mot en SUV. Behöver du SUV-attiraljer så är det en SUV du får köpa även om du inte tänker utföra sport-aktiviteter med den. Sen kan jag hålla med om att distinktionen börjar kännas onödig, men många är nog glada att de slipper betala för Pro när de inte behöver det i alla fall.

Jag ställer den viktigasre frågan först.
Vart då? Om man använder den inbyggda tjänsten så kostar det 1499kr.

Remote Desktop och domänstöd är i all högsta grad homesaker idag, även om man ej har en domän hemma privat så har nätverken som man ansluter sig emot detta. För 5 år sedan var det dock annorlunda, men det blir allt mer nätverk mellan ens datorer idag. Remote Desktop så är det väldigt ofta man ska in och pilla på någon dator utan att behöva gå dit, likaså kanske någon redan sitter vid datorn och man då vill logga in med en ny användarinstans och göra saker som att underhålla/konfiguera datorn under tiden någon arbetar med denna.

Spara det man håller på med? Många har tjänster en drös med virtuella maskiner igång etc, det är inte bara att "rycka ur sladden" för dessa" och hoppas att man senare har tid att åtgärda dessa. Nu gick denna funktion dock stänga av i home insåg jag. Men som du sist skrev så bör dessa datorer ej köra home, problemet är att det gäller varenda dator som jag använder, inte ens en terminal duger home till ty avsaknad av domänanslutning.

1000kr extra vid nyköp, 1500kr extra om man ska uppgradera via den inbyggda funktionen i windows.

Jag skulle knappast kalla services som något avancerat och fler och fler program körs som detta idag, det är för att de alltid ska vara igång oavsett vilken användare som är inloggad. Sitter man då och utvecklar som jag gör så är det något man hela tiden startar och stänger av, speciellt när man utvecklar just services.

Nu fanns dem dock enkelt via kontrollpanelen, det jag störde mig på var inställningar som lurar folk att tro att denna skulle vara en ersättare. Liksom det finns väldigt många duktiga IT folk, men alla har ej pysslat med alla operativsystem och det är lätt att tro att just inställningar är allt.

Pro är det man minst behöver, köper man en ny laptop så är det home på de flesta och man är tvungen att betala dyrt för saker som borde vara standard år 2015.

Bilexemplet brister på att fysisk hårdvara kostar pengar, i windows handlar det om att spärra home editionen så att vissa saker ej fungerar.

Nå det mesta handlar om att jag tycker 1500kr extra för att uppgradera till pro är för dyrt, vet du var man helt legimt kan fixa det för 1000kr så har problemet redan minskas en 1/3. Skulle kostnaden varit 500kr så hade jag tyckt det vore helt okej, även om 500kr per dator tillslut blir en hel del pengar det också.

On an unrelated note, har tagit bort lite skräp som "Skaffa Skype", "Skaffa Office" och "Microsoft Wi-Fi", helt enligt spelets regler (avinstallera via startmenyn), men de verkar komma tillbaka lite på måfå? (möjligtvis i samband med uppdateringar) Vad är grejen med det?

Installerade om min dator med Win7 Ultimate och stängde av allt vad uppdateringar heter, för att slippa dessa Win10 popups och tvångsinstallationer. Detta har fungerat ett tag nu..

Men idag ploppade det upp att "du har uppdateringar" och Microsoft har återigen gått in och ändrat mina inställningar till "automatiska uppdateringar", från att den inte ska kolla alls.

Nu är jag väldigt nära att ta ett lån, bara för att kunna skaffa min nya Mac.. Vill bara komma bort från diktatorn Microsoft så fort som möjligt.

The testing you described where the developer tests their own code does not work well. Developers rarely do a good job testing their own code. The developer is to invested in the development and it blinds them to proper testing scenarios. If they've developed a good testing script/checklist, then that will help alleviate the issues, but testing is always better from someone who is not involved with the development.

Yes. This is the same reason writers rely on proofreaders and editors. Secondly, good coders are not necessarily good testers. Thirdly, when coders are testing, they're not coding. Fourthly, the added stress can affect a coder's clarity while coding.

Clearly Microsoft has gained a lot of valuable testing with the Insider program, and it makes perfect sense that they're doing a lot of telemetry to spot both specific problems and also general trends. Time will tell if this strategy is enough.

Now, I believe Nadella is a pragmatist, so I think he'll change the process if it's not working. But since it's a new system, he'll give it some time to sort out. Just my guess, but I imagine that Redstone will be an inflection point, when he decides how to proceed. Certainly it's an important milestone, and far enough out to give time to judge their progress.

After the layoffs, which gutted a significant portion of the employees who were in the testing group, management pushed down the idea that developers should be fully responsible for their own code. This, in itself, is not a crazy idea, but the transition to this methodology is starting to show its weakness in the products that Microsoft has been shipping since the release of Windows 10.

For decades, Microsoft utilized its older workflow of including having an extra step to allow code to be fully tested, but this came at the expense of increased development time and longer cycles between shipping products. While the idea of holding developers responsible for their own code is not outlandish, the issue comes with how quickly the transition occurred.

For employees who had been working at the company under Ballmer or even Gates, switching methodology, almost overnight, to now having to code and fully test your application came as a shock to the traditional development cycle. According to several people familiar with the new process who asked not to be named, the new workflow caused issues for developers as they were not quite sure how to balance time devoted to testing versus building.

Further, having spent years coding and not performing detailed and prolonged testing, their methods for quality control were not to the same standards as those who were dedicated to the task.

Under the new process, the time allotted to building out new features includes testing the code as well, which it previously did not, which means that those engineers who are accustomed to the old style, now find themselves under more pressure to turn out quality code in a shorter period since they have to do the detailed testing. The end result, as we have seen with Windows 10, is a product with more bugs and its starting to show the weakness of the new process flow.

I think Brad's sources are probably those disgruntled employees who are struggling themselves, which resulted wrong information presented in this article. Anyone who is aware of modern development processes (especially TDD), they understand it does not diminish te role of QA . However, older developers always struggle to understand the role of QA and tester clearly. This is what is happening here. I think Satya pushed for better testing and everyone know developers need to write Unit and integration tests.

Obviously it takes significant investment in terms of developers time to write those and then maintain them. If you have grown up without these methodologies then it really hampers your performance. However, I would expect developers working a company like microsoft has enough skills and capabilities to get past such hurdles rather then making lame excuses. Embrace the philosophy properly.

I'm going to go ahead and trust my sources who I would not classify as disgruntled.

I think you missed the point of this article, everyone knows that this model should work better but do you know how many custom lines of code are in Windows simply for printers and specific hardware?

Windows is not a small project and therefore what works for companies with small software projects does not work for something that is used by billions of people daily.

^ This. As a developer for a large tech company, this post is spot on. We've always been partially responsible for our own code and when things need to be cut, the QA department is usually the first to be reduced. But I struggle to think outside the box with my own code. I know how it works and what to expect and can't always approaching testing with an open mind. I think subconsciously I don't really want to break my own code.

By definition a software developer cannot test their own code period. I know this from 20 years of software development experience. Anyone who thinks a programmer can test their own code is smoking a gigantic crack pipe. Developers will run over their own mistakes and not see problems that a different set of eyes will find. This is true 100% of the time. No wonder Microsoft is having such problems.

The issue, as I've seen it, is not that bugs are not being found/reported, but that so many are not even diligently triaged, let alone addressed or fixed. Too many of the issues that actually get discussed, get either the Jedi hand wave (aka 'Not Repro'), punted as 'Won't Fix', or postponed to a later milestone. As that later milestone nears, the issue is so far down the backlog that nobody looks at it anymore, or the vendor PM who was tracking it is long gone and nobody picked up the dropped ball.

Very true. The devs are now adding testing and program management work to their schedule, and are still expected to produce new code. They also have to work with the support teams to triage and fix critical bugs.
Coding, testing, program management, doc writing, all have different mindsets. Someone really talented and experienced, can switch between them, but it adds a tremendous amount of stress. The number of hours worked per week has gone way up with very little compensation for the added hours.

11 year Microsoft employee here. Microsoft removed, to a large extent, the distinction between SDEs (Software Development Engineers) and SDETs (Software Development Engineers in Test), which meant the weird "I write the code, you write the automated test cases" issues go away. This was/is a the right thing to do and mirrors the Test Driven Development (TDD) patterns that have emerged as the forefront of modern development practices (SQLite is a good example of this).

Microsoft did not remove QA, i.e. the manual test cases and opportunistic bug finding that has to occur before any public release.
This article is mostly bogus AFAIK - the bringing of SDETs into the engineering teams is A Good Thing(™)

Really? Which division?

I know OSG got hit really hard. I didn't lose my job during the layoffs because by that point I was just a contractor so I got out (about a year) before the 18 months 'persona non grata' deadline could elapse. But in DevDiv, all the SDETs were converted to data analysts of the CEIP (telemetry) data. The ones that weren't laid off, that is. So while the majority of people were still employed, they were no longer writing or running tests, or analyzing test results and filing bugs.

Having been an SDET (Software Developer Engineer in Test) in the Windows organization a few years ago, I can tell you one of the issues plaguing the team is their legacy code base.

They rely heavily on lots of legacy C++ that has no unit testing at all. Full end-to-end testing of each code path is simply unfeasible for such a monstrous piece of code. They do have suites of UI automation tests to cover major scenarios, but the test matrix is far beyond what can be reasonably covered, and the tests execute slowly sometimes. Unreliable tests can become disabled and lose their value.

C++, while very powerful and fast, has many issues which can make it difficult to scale in terms of complexity. Sure, it has a proven past in many applications, but very few developers ever work on a code base nearly the size of Windows. I hope the future of systems programming moves to a modern alternative (perhaps Rust, though I've never used it).

Another problem is team turnover... it takes several months to get familiar with a code base to where a developer is able to quickly, and correctly, fix an issue. Windows is notorious for having major reorgs every major release... this often encourages or forces developers who have the Windows code tribal knowledge to switch to another team, causing another developer to start from zero. Having major reorganizations can cause quality issues down the road.

I honestly do think that the legacy C++ codebase is a bit of a liability. The tooling for doing things like recording how a heap corruption happened just aren't there (if your problem isn't easily reproducible). I actually feel the same in Linux, although the tools there are slightly better. When you're working on a product that gets used on literally billions of devices every day you get some really hard to reproduce issues. You have enough data to tell the bugs are genuine, not just some flaky hardware, but it's literally impossible to repro them or debug them. This doesn't happen for code written in C#/Java or to some extent modern native dev languages.

I have to agree that developer/tester churn was inevitably going to decrease quality in Windows at some point. This recent layoff round targeted a lot of the more senior people in Microsoft, with the goal of making the company a little younger and lowering operation expense. I suppose I buy in to the idea that it will bring fresh ideas into the organization as well.

I actually feel that most of the bugs I've seen in Windows 10 are related to integration problems, especially focused around integration points and the WinRT API. The API assumes so many things are silo'd, it restricts your code from accessing so much in the name of speed and security. It means if you have some code that needs to access several files there's arbitrary limits imposed on you as in the future access list limits. I assume this is what caused so many problems with the start menu. There's also all kinds of issues with the Mail app I've seen where it gets permission denied errors when working in multi-user mode, and then it doesn't handle the errors properly and crashes over and over again.

These are relatively obvious problems, they should have been caught in integration testing, and I think if more of the SDETs were still employed with MS they would have been. In the long term I think code that makes use of WinRT API are going to have to have some kind of permissions granted to them that gets rid of any arbitrary limits. You could restrict this permission to system code signed by MS, and third party code that the users or OEMs grant permission to.

Dhanunjaya Naidu Yandrapu, Worked 7+ years for Microsoft as a developer

There is no SDET position in Microsoft right now. The SDE and SDET roles are combined and simply called as Software Engineer (SE). SE is responsible for coding and testing. So just apply for SE position.

All SDE (Software Development Engineer) and SDET (Software Development Engineer in Test) positions have been renamed to SE (Software Engineer). In theory, that means that all engineers are now writing code and tests to ensure quality. Previously, SDE's wrote product code and unit tests, while SDET's wrote test automation (more blackbox type testing generally) and did more rigorous testing.

In practice, this varies by division. Operating Systems group (OSG) still has the "trio" of Developers, Program Managers (PM), and "Quality" (formerly test). Engineers in the developer and quality trees have been renamed to software engineers, but for now they are still very different roles. Developers still write product code and unit tests, but they also write more test automation. Quality SE's write a smaller subset of automated tests and supposedly work on adding "telemetry". The idea is that they will add all this data collection about performance and crashes so that real user issues will surface to Microsoft automatically.

However, for the time being, this means that the former SDE's have the same amount of time to try to accomplish more work (product code and test), thus we either need to add less features, write less automated tests, or both. The former SDET's seem to have fewer responsibilities currently, but their numbers have also been pretty significantly reduced.

I can't speak for other org's but time will tell how this works out for OSG. There is definitely a shift to align better with the way other tech companies handle this division of work. Microsoft has traditionally had huge test teams and there may be value in having the same developers write both product code and test. But for now, it just seems like we lost a bunch of people and tried to keep up the same amount of work.

It was announced that the test and dev organizations would merge. All test folks would become developers. This pretty immediately caused a variety of reactions, among them:

• "But I'm comfortable in my role."

• "But my job isn't to test software."

• "But my job isn't to write software."

• "But I can't do the job I wasn't doing before."

• and more bullshit.

Here's what happened. Here's what I (personally and not speaking for anyone but me) believe was meant to happen. The people best suited to this new world thrived. The people who were adaptable adapted to the new world. Less talented people either saw the writing on the wall and left or didn't see the writing on the wall and lost their jobs.

Basically, harshly, adapt or die. I'm sure I'll be on the wrong end of this sentence later in my life too. It's not a nice sentence and I understand that.

Make no mistake, combining 1.5 or 1.75 jobs means less jobs for folks. This is, plainly, visible. And developing and testing software are, at least to Microsoft now, the same job. Whether you see this as evolution or trying to squeeze blood from a stone, the reality is that those things that were separate are now simply not.

The first question a smart observer will ask is: "so you got rid of all these testing specialists. Didn't your quality suffer?" No. No it did not. And on top of that our agility (as measured in velocity to ship changes) improved. Our collaboration improved. Life, overall, got better for the organization. I believe we are faster, leaner, and better for it.

Why? There's just less stuff in the way. Leaner organizations execute faster. This is why startups are so fucking fast. There just aren't a lot of people so squabbles are easier. Not that startups are the best, but just as they are not the best for good software nor are huge monolithic organizations. A happy medium must be found and maintained and nurtured.

Kommentarerna från Ars är lite mer insiktsfulla kanske. Om MS tidigare skilde på den som skrev kod och den som skrev enhetstester för koden så var inte det bra enligt dagens best practices och detta är ett steg mot detta ideal, att låta/tvinga utvecklarna att skriva sina egna enhetstester. Att flytta personal precis när de börjar bli bekväma med en arbetsuppgift är förstås sällan en bra idé varken inom utveckling eller inom arbetslivet i stort och om MS gör det så är det inte bra på något sätt, men jag vet inte om det faktiskt är så generellt eller i enstaka fall (eller inte alls, det är bara en anonym kommentar trots allt).

The agile approach of combining development and testing, under the name "combined engineering" (first used in the Bing team), is also spreading. At Bing, the task of creating programmatic tests was moved onto developers, instead of dedicated testers. QA still exists and is still important, but it performs end-user style "real world" testing, not programmatic automated testing. This testing has been successful for Bing, improving the team's ability to ship changes without harming overall software quality.

However, there are costs to this setup. The recent layoffs have been poorly communicated both within Microsoft and beyond, but one victim group appears to have been the dedicated programmatic testers in the Operating Systems Group (OSG), as OSG is following Bing's lead and moving to a combined engineering approach. Prior to these cuts, Testing/QA staff was in some parts of the company outnumbering developers by about two to one. Afterward, the ratio was closer to one to one. As a precursor to these layoffs and the shifting roles of development and testing, the OSG renamed its test team to "Quality."