Discussions

3 hours ago, Bass wrote

This Microsoft development model you keep describing sounds pretty political and bureaucratic.

Not really. It's the same with any company. If you're StartupCo it's the same too. You can't make your product do everything, so you have to decide what features are the most important. Of the 100 features you want StartupCo's product to do, you can only do 10 of them really solidly before you launch the product in two months' time. That's not to say you don't want to do the other 90. It's just that you'll do the other 90 later.

If you get feedback from 1000 customers about features they want, you have to prioritize. Some of those suggestions knock back features you were going to implement (at the end of the day, your product is for customers), but sometimes customers ask for ideas that are a lot of effort to implement, and the benefit is low compared to spending your development effort on something else. For example, having your website auto-branded to their company is something that's less important than getting the core features of the product out of the door. Making your website work on IE6 is less important than getting it to work on Google Chrome and IE10. It's common sense really.

Similarly if you want your idea to be implemented in StartupCo's core product, write them an email telling them about why your idea is good. Don't write them an email about how StartupCo is rubbish and you hate their product. It's common sense.

If you write feature requests written in toxic language, you won't get people to listen to you. Why should I care about your ideas if you're going to be rude about StartupCo and the employees and the hard work they put into the product? Screw you, find a different product.

Requests that are framed in positive language always do better than ones framed in negative. And being polite and respectful never hurt your chances of getting your feature into a product - at Microsoft or anywhere else. Some of our contributors on C9 would do well to learn that if they want anyone to ever take their ideas seriously. 

4 hours ago, DeathBy​VisualStudio wrote

And where do those constraints come from? Executive decision.

They come from the fact that feature requests grow to fill the number of staff available. If Microsoft doubled the number of engineers in every team, PMs would still have to decide which features not to ship.

I don't know about you but when we're trying to figure out where Microsoft is going I think you have to look at what they've done in the past (especially now that they've curtailed sharing anything other than a curated vision of the future). That means we'll continue to talk about the death of SL in the same breath that we talk about what is to come. Maybe I'm just out of my mind to think this was a place to discuss the future of Microsoft's technologies...

Sad as it may be, Silverlight is not the future of Microsoft's technologies.

14 minutes ago, wastingtime​withforums wrote

Yes, I am aware that you can install third party (paid) software on Windows. Thanks.

Are you claiming that included software doesn't add value? Was the Live Essentials suite pointless?

You can also install third party (free) software on Windows.

And, yes, also you can install first party (free) software on Windows.

Also, Windows Live Essentials didn't ship with Windows either (and still runs on Windows 8), so I'm not sure what point you're trying to make is.

No matter how much you might want it not to be the case, the apps that ship in-box aren't interesting. Because Blue still ships with the only app that matters, i.e. is this one:

48 minutes ago, contextfree` wrote

I'm not sure I agree with this. An important part of being a PM, product planner or UX professional is being able to take feedback that might be emotional, angry, confused or even incoherent and make good use of it anyway. If they only paid attention to feedback from people who "thought like MSFT executives" they'd wind up tailoring their products to a pretty narrow slice of their userbase.

If anything feedback of the form "I hate Windows 8 and I hate you because it installs a new facebook that broke my googles, bring back the old facebook with the dog!!!" is likely to be taken equally seriously as some developer's politely worded "constructive" suggestion with an elaborate logical argument backing it up. In both cases your unhappiness will be taken seriously, your suggested solution will be ignored and your given reason will be treated as an indirect clue to the puzzle of working out the real reason for your dissatisfaction

PMs have no shortage of people with opinions on how to make the product they own better. The shortage is always in amount of staff-time available to do all of the neat things you want to do with your product.

This is why if you want to make an impact on a product team, you need to learn how to phrase your request to get into the top 10% of their list of 30 awesome ideas, so that it will be implemented.

If you wrap your gem up in a toxic blanket of anti-Microsoft venom, then a PM won't waste their time trawling through your text to see if there's a gem hidden in there. They'll just straight on to the next guy in the queue to their office to give an opinion on their product.

And you don't need to think like an executive to get the attention of PMs. You just need to think like one if you want to reverse a big decision like the lack of start menu, or the introduction of Windows Store, which are all of the decisions that DBVS wants looked at.

40 minutes ago, DeathBy​VisualStudio wrote

When is it ever not an executive decision? Even bug fixes fall under executive approval to some degree as they decide the budget and time constraints.

When it's an engineering decision. For heaven's sake, DBVS. Learn to read.

Also bugfixes are never executive decisions. Think about it this way. An executive decision is one made by someone earning $2,000,000+ a year and who has a personal secretary who prints off their calandar appointments for the week which are mainly meetings with people who manage people who manage people who write code.

If the decision doesn't impact a $10m investment deal, it doesn't even get onto the VP's calendar for a 10 minute chat. That's where executive decisions are made.

Executive decisions are the big, strategic decisions that make a difference to Microsoft 5 years from now. Like killing Silverlight, introducing the Ribbon, focusing on security, bundling flash with IE, making the Surface, inventing WinRT or introducing the Windows Store.

Don't waste your breath trying to persuade the developers who frequent C9 that the executive decisions are wrong. Even if they believe you, they're not silly enough to say. And even if they wanted to, they're nowhere near the grade required to reverse the strategy.

If you want, start a blog. Then you can shout and stamp your feet at the top of your voice and as hard as you can. Maybe you see if shouting louder makes the tumbleweeds roll faster.

But please, I'm pretty sure everyone in literally the entire world is bored of the discussion about start menus and Silverlight. Just, please, for heaven's sake. Just get over it. Yes. Microsoft is evil and kill puppies and are the reason Unicorns are extinct. Whatever. Just stop going on about it. The whole conversation is so far beyond tedious it's unreal. It's just you on your little soap box shouting at the top of your voice at the literally nobody that cares.

1 hour ago, DeathBy​VisualStudio wrote

So why do you assume that when I say "things move slowly" that the source of the slowness and the basis of the complaint is from the diligence required to maintain a huge and critical code base? A lot of the slowness is from politics and the inability to turn criticism into improvements.

Yeah and we know how well those feedback buttons worked for Office, W8, and the W8 Store Apps that Microsoft produced for the initial release. Again because of politics and the inability to turn criticism into improvements these "feedback" buttons are pretty worthless.

You seem to consistently confuse engineering decisions with executive decisions.

Feedback to developer teams about crashes, distracting UX changes and features that are required by consumers of services are dealt with pretty quickly at Microsoft, certainly compared with other products with similarly large user-bases.

But decisions such as the Office Ribbon, losing the Start Menu, the Windows 8 Store, Windows Phone 8 and Windows RT itself aren't developer decisions. They are executive decisions. Although some are concepted and are certainly usually implemented at the SDE and PM levels at Microsoft, the decisions are usually made much further up the chain, by GMs and VPs.

For example, the decision to go for the Ribbon in 2007 and for Office 365 were made at the top of Office. Windows Store, Windows RT and dropping the Start Menu were decisions made at the top of Windows as part of Windows strategy. Not part of Windows engineering. The decision to drop WinPho7 support, to kill Silverlight, to drop XNA and so on - none of these are engineering decisions. They are all executive decisions about restructuring and reprioritizing DevDiv.

The reason this distinction is important is that engineering decisions are agile. Yes, it's not hard to add a page; a config setting; a parameter or a flag to that function. Yes, we can expose this interface, or add this or that feature. It'll go in the pile of 30 requests, and if it's in the top 10% we'll make it before the next release of the product, otherwise it'll have to wait until later for consideration. It'll probably be usable and stable by endusers and other teams within a year, and usable by other developers within the team a month of two.

But executive decisions don't work like that. These decisions are made based on market data, industry movements and shareholder feedback, not some single user's "feedback" on C9. You can literally scream until you are blue-in-the-face about the Start Menu, the Ribbon, WinPho8, how you think Microsoft shouldn't bother with the Surface, how you want them to Open Source Windows, how they killed Silverlight and XNA, or how you don't like Office 365.

It will make no difference.

Executives at Microsoft and elsewhere make big decisions, and then they go with it. You don't get to be an executive at Microsoft or anywhere else by asking your engineers to do massive upheavals and then chickening out because a couple of blogs don't like your interface but before you've actually given it to customers to have a go.

Some decisions are right, some are wrong. The decision to introduce UAC in Vista, for instance, was the right decision, although it was unpopular at the time and we can argue around the houses as to whether it was correctly implemented in the first place.

The Ribbon in Office, likewise, had its opponents screaming for heads to roll and third parties climbing over each other to skin the new office and "bring your menus back". But in the end, the decision was right. People found features faster and more consistently in 2007 than in 2003.

I know it's a hard concept to grasp; that perhaps Steve Sinofsky didn't pop open Visual Studio and personally implement the Start Screen himself. And I know it seems impossible that a PM I reading C9 couldn't have said "by goodness! DBVS is right!" and file a bug to request that the start menu be returned. Or that the Silverlight team was disbanded on a whim because they got bored of writing SIlverlight, or because they all agreed amongst themselves that HTML5 was better and they should probably stop.

I hate to break it to you, but real life doesn't work like that.

The reality is that if you want to influence executives at Microsoft, you need to think like one. And they aren't going to reverse a decision they made 3 years ago, committed literally hundreds of man-years to as part of a 10-year investment strategy at the whole of Microsoft just because some whiney journalists on the Internet think that the Windows Store is a bad idea. They think that everything Microsoft does is a bad idea, and Microsoft just ignores them. Besides, they're not evaluating WinRT right now to see if they should can it. They're evaluating it to see how much further they can push it. The decision to put it into Windows Blue and Windows 8.2 isn't being made now - it was made years ago when they started it back as an interesting project in mid 2010.

They knew Windows Store was going to start off empty. They knew going full pelt on WinRT was going to be unpopular. Windows8 doesn't even really matter, because it's not a product, it's an iteration. It's not about taking people from Windows7 to perfection. It's about being a stepping stone from where we are to where we want to be. 

That's the difference between executives and journalists. Journalists and users see products. Executives see product lines. And where journalists are using Windows7 to write blog posts about changes they'd like to see in Windows8, or complaining that Windows XP is going out of support or using crystal balls to try and work out what might be in Windows 8.1 - the decisions being made now aren't any longer about what to put in Windows 8.1, but rather what needs to slip from Windows 8.1 to Windows 8.2. And new ideas invented today will almost certainly not see the light of day until the Windows after that.

And that, DBVS, is why you utterly fail to make a dint in Microsoft's decision making. You're complaining to C9 engineers about executive decisions they don't control. And, supposing there are any executives here, you're telling executives about decisions that happened so long ago that they're not only locked in - they've basically been completed.

You're not making any impression on them, because you're not talking about where we want to be, given that we have WinRT, and given that Silverlight is dead, and given that Office has a Ribbon. You're talking about revering those decisions. And so as far as anyone making those kind of decisions is concerned, you're living in the past.

If you want to influence engineers, tell them how to make their product more useful to you, and avoid asking for executive decisions to be reversed.

If you want to influence executives, and hence Microsoft's entire future direction, talk about what Microsoft's role is in a world where Xbox, Windows Phone, Windows Surface and Windows have converged in 2020, and what Windows should look like then. Talk about whether it's even possible for apps to do all of their computing in the cloud, and whether users want that. Talk about whether Xbox can be used to gain marketshare on Phones, and whether Phones and the Xbox and hell, why not your fridge and your car, might one day run something that's the same as Windows.

Constantly ranting about start menus and winrts is boring to everyone. It clearly didn't work to complain about it during the past 12 months (and that was certainly not due to a lack of complaining here on C9 by a great deal of people).

It time to stop complaining about where we are and start talking about where we would like to be. That's a conversation worth having; it's more positive; it's less toxic; it's more interesting and it's more likely to end up with you being able to influence Microsoft. 

15 minutes ago, DeathBy​VisualStudio wrote

It also sucks that it seems we just all so readily accept the fact that this is just life in big companies; things move slowly, politics are as important as the work, criticism is unwelcome, etc

Wait. What? The reason things move slowly at big companies is because change is managed to make sure that products that consumers use is stable and safe. It's a big deal if you ship a version of Windows that kills all of the batch files that literally the entire US financial system run on top of, for instance, and so for every week you spend writing code to edit cmd.exe, you probably want to spend 3 weeks making sure you didn't just introduce a security vulnerability, a performance hit, an app-compat hit and that it works kinda like you said it would.

That's something startups just don't care about.

Also, I'm not sure that criticism is unwelcome at Microsoft. In fact all of the products used at Microsoft have big "feedback" buttons specifically inviting criticism (you can see it in some of the C9 videos. It's usually a button that's always visible in the top right or bottom right of every website and app that Microsoft builds).

The difference is between giving useful, actionable feedback versus just being a douche-hat. Maintaining a dialogue with the product team to let them know your concerns and requirements about their product is in the former category. Publishing your beefs on the Internet, or stamping your feet and saying that they are wrong about everything from NTFS to the C++ compiler to Powershell not being in CMD.exe is quite firmly in the latter.

4 minutes ago, BrianD wrote

IDK why people are assuming it is an junior dev. 

Because senior devs don't write bitchy career-limiting letters on the Internet. The only time a senior person would ever write a letter like this would perhaps be one accompanying their letter of resignation, and even then, only if they were absolutely sure they weren't going to want a letter of commendation or to ever return there.

Also, the guy is complaining about stuff that shows that he doesn't really understand how software is written in big companies. Like complaining how teams don't like "outsiders" coming in and writing code on their turf.

Well, no poops, sherlock. Of course not. Writing code is the fun part of being a dev. It's maintaining it, integrating it, testing it, regression testing it and shipping it that are the hard bits that take up time. And the fact that you just came in and dumped some source code on their doorstep doesn't help.

Apart from the the fact that you might not understand the context of where the team are in terms of other priorities - maybe that check is there for AppCompat reasons, or for performance reasons, or adding code here introduces a bug over there - if they add your code then that pushes back the testing schedule, and that means deciding which of their 30 good ideas from the planning round they need to drop in order to add and maintain your code.

As Raymond Chen put it, you ran over to the other team, ate the meat from their plate and are expecting them to finish off the vegetables.

Also, look how telling these paragraphs are:

These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones.

(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)

How is it news that writing new code is easier than fixing old? New code uses newer code patterns, newer syntax and generally better stuff. Older code might have been written before stack overflows were an issue, the developers have all left or died of old age, and you're left with massive app-compat risks that new code just doesn't have.

Yes. You could have updated cmd.exe to be Powershell. But look! suddenly you've broken the entire enterprise market that only manages to get to the desktop through some ricketty maze of batch files and visual basic nonsense. Do you really want to start kicking at the foundations on which literally billions of dollars of ricketty unstable businesses are built? Any developer worth his salt knows to leave that stuff well alone.

That's why it's an obviously junior developer. Look. He even says so himself (in not so many words):

You find SDEs and SDE IIs maintaining hugely import systems.

If that doesn't scream "I'm an SDE I or SDE II, and I do really important stuff", I'm not sure what does. Junior devs maintain really important systems. Senior devs design and build really important systems. All that sentence says is that the person that wrote it hasn't seen further up the tree than an SDE II.

21 minutes ago, blowdart wrote

I'm more bemused it's proof of anything. Gee, it's not like anyone outside of the kernel team could produce a SHA1 hash... oh wait a minute...

It there to raise the bar of authenticity. It (nearly) proves that they can see the source code, or at least, that they know someone who can, and it's designed to dismiss the obvious suggestion that the post is entirely fabricated by someone with a grudge against Microsoft who's never worked there (like, say, beer28).

What it doesn't prove is that the person is a Microsoft FTE, or that they work in the team responsible for building and maintaining that code, or that any of the content of post is true, or that they have current read access to the source code etc etc etc, but then again, it wasn't designed to do that.

It's an intractable problem both proving that the post is genuine and simultaneously maintaining anonymity. The SHA-1 hash was just there to provide enough evidence that the poster is an MS employee to make it news-worthy and to avoid people dismissing his rant without giving away any information that might allow an internal witch hunt to find him and fire him.