Dave's Box

It's interesting that your first thought while responding to Jeremy and Ayende is to make excuses and defend the problem rather than seeking the solution.

Instead of making excuses for convoluted process, self-imposed archaic and backwards design rules, and poor design overall, maybe you should be engaging Jeremy and Ayende how they manage their frameworks and how they are able to avoid the kinds of problems in which the Microsoft, BCL/API team(s) seem to keep finding themselves.

Using language like "we don't have the luxury" (which implies that Jeremy or Ayende aren't smart or experienced enough to know the problems with public APIs) is not helpful and is insulting.

The larger point that Jeremy and Ayende are making is that the rather lengthy and complex process you have for releasing APIs may be the problem here and that because Microsoft has such a complex and convoluted process teams are AFRAID of making things public when they really should be.

It's simply easier to make things private/internal than to think through what might be best for the customer.

Microsoft have chosen their rules on API design and the point is that perhaps these rules are hampering quality software and are a detriment to its users over all.

In the effort to protect them from future problems you may be holding them back now.

There's also the larger issue of poor API design that necessitates this type of protectionism mentality.  If the framework and API were designed with IoC, dependency injection, interface segregation principle, and other core design principles in mind versus strict inheritance over composition, the problem that Jeremy and Ayende mention either wouldn't exist, or would have other remedies without having to be fearful and making everything private/internal.

Follow-up:  I did want to temper my response by saying that the things in your process are necessary and important. We all understand and appreciate that. We also appreciate the quality of the BCL API's in general.

But there are ways of achieving this level of performance without compromising on the design of the API.

When you say "we don't have the luxury," I say: "Why not?"

Perhaps you should say, "We choose not to have the luxury" or "We have created an environment where this sort of change is not reasonable to do" as these are closer to the truth.

Dave,

All this is saying is that Microsoft's organization is completely screwed and attests to their continuous head-in-the-sand approach to organizational practices like those used at Toyota.

You've done a good job at communicating why the organization can't handle situations like the one Ayende and Jeremy are pointing out, but you haven't offered any insight into why Microsoft can reform itself toward an organization that wasn't hatched in the dark ages of the early industrial revolution.

"It is for these very reasons, we try to make our extension points deliberate and designed."

Here's the problem, if people like Jeremy Miller or Ayende (or any other hard core user of the framework) say that something should be public then you missed a necessary extension point.

Your reasons are fine, but ultimately you should be listening to people in the community on these issues and making changes (adding extension points) to make the experience better.

You are quite correct. Creating APIs is hard. Microsoft has and WILL get it wrong. I think you need to take a moment to introspect on a culture that views change as scary.

I feel that Microsoft's culture of backwards compatibility as a must have is a broken principal. .Net for a long time has included an obsolete tag for a reason. People do make mistakes and better ways are found to do things. We improve ourselves our code and so should the framework.

The solution is simple: don't listen to these simple folk. You work for a multi-billion dollar company, obviously you guys are doing things right. Remember, opinions are like assholes, and I hear these ALT.NET people have a lot of those!

Take it from me, the very worst thing you could do is change a process that's worked for you in the past. Oh sure, you'll hear that others are doing things differently and more "efficiently" but that's just their honeymoon phase. Every company goes through that, but you aren't just any other company, you're a great company and far beyond the need to improve on a process proven to work when you had no competition.

davesbox.com/.../quot-i-can-t-believe-microsoft-didn-t-make-enter-api-name-here

I fully understand why you need to be careful about exposing too much (though I would argue that to many of us indefinite backwards compatibility is not something we need) but I still think there is probably a way you can harness the knowledge that these people have about problems using some parts of your framework. So I was wondering whether you have thought about creating a site where people could report missing extensibility points?

@Richard.  Seriously? You gauge the net worth of an organization as an indication of whether it's right, wrong, or needs to fix something?  I'm just glad that other industries don't follow that, I'd hate to see Toyota view its dominance and its bank account as the deciding factor whether they should recall something because of a defect.

@Peter: "Richard" was a sarcastic joke (note the link to his name).

While clever, it doesn't help the discussion and distracts from good discourse.

RABBLE RABBLE RABBLE

Consenting Adults

(Disclaimer: I work for Microsoft)

Looking at the list of archaic reasons, I wonder which ones people would like dropped?  If the security review was dropped and a security vulnerability found, people would scream.

Localization?  Sorry you guys in Germany, docs are English only.

Proof-reading?  Alright, this *might* could be dropped.  But then the public would laugh at our run on sentences or fragments.

Some of the bureaucracy (25 managers, 2 VPs, etc.) could probably be streamlined.  But that's well above my pay grade...

I guess I don't see how the process he mentions is convoluted or archaic.  It is the process of a global company that has been dogged in the past because of security vulnerabilities.

Now with respect to backward compatibility and api design...

When everything was C based, it made sense.  You didn't want people to have to recompile to run their Windows 95 apps on Windows 98 (or NT).

But I thought one of the goals of the .NET Framework was side by side execution?  I.e. if .NET 4.0 removed an API, just ship with 3.5 and make sure your assembly bindings are correct.  If you really want that 4.0 API, then you gotta deal with the missing API.

Breaking backward compatibility in .NET 4.0 is probably much easier than breaking...say...Kernel32.dll.

As for API design, I personally like the Java approach that everything is virtual.  I think we should stop treating developers like children.  Maybe we should publish our test cases and say "caveat emptor if you use beyond these test cases".

I do find it interesting that DI and IoC were brought up.  .NET came out in July 2000?  I'm sure there were pockets of people living the DI/TDD lifestyle, but it really didn't hit mainstream until 2003 (granted I was in Java world at the time and Spring had just been released. Pico was out, but didn't have the momentum that Spring got).  Microsoft couldn't divine that it was going to be so big.

But that brings us back to breaking backward compatibility, side by side execution, yada, yada, yada.

Sounds like it will still take time for the mentality shift towards approaches like their asp.net mvc is being developed. Instead of doing "behold, this is our new all-mighty product" to beta testers and then release it to production they might try more incremental beta releases to wider community.

Well, Ayende's code is hard to find, sometimes doesn't build, has had dependencies all over the place - isn't document - typically is left unfinished with alot of fanfare when it starts.

I like Ayende, but let's not crown him yet Chad - I see it as an assortment of code he used to solve his problem then openly shared - left for you to figure it all out.

I would suspect that MS can't just throw things together like that and modify it 'whenever'.

I also would suggest you haven't even come close to writing an API used by as many people as MS  :)

David,

I posted a article on my blog on this subject.  Why Public Virtual Ubiquity Would Fail.

jeffhandley.com/.../why-public-virtual-ubiquity-would-fail.aspx

Jeff Handley

"Or should we be targeting the other 95%?"

The truth is most of us now use a lot of open source tools and rely on them, I'm not saying its an easy decision but I do think you should be considering how to make it easier to add extensibility points.

@Chad: Oren isn't the main developer of nhibernate. He did/does a lot of work for it but Fabio does way more. Using Oren as an example how he manages his framework is IMHO not giving credit to the right people.

Dave,

>> Developing good APIs is extremely difficult, especially the first time around. When we get things wrong (and we do get things wrong), trying to maintain backwards compatibility often stifles innovation as we try to correct these scenarios. Unfortunately, unlike others, we don't have the luxury to make only 95% of our new versions backwards compatible with our previous versions.

From this paragraph I can tell that you didn't do any assessments of breaking changes over the past products of Microsoft, and that sentence to the reference is both insulting and misleading.

Don't go too far, just look at the list of breaking changes from 1.0 to 1.1 and 1.1 to 2.0 .

If not enough, go to compact framework forums

Ah, are these too old ? Wait for the new EF 2.0   and watch Microsoft touching that 100% ceiling. So for WWF.  

Not even mentioning the projects that are dropped and couldn't even reach to the point to be represented by a percentage sign.

As a customer, I want the platform that I consume to be more suiting my needs. Am I unreasonable? Sorry, but I don't care how long it will take because of 2 things :

1 - I am a customer.

2 - The issue causing this is by (bad) design, and the former point also states that I was not the one who did it, so why am I paying the bill ?

I hope this is not the general perspective in Microsoft since there will be no major improvements and shows that everybody is afraid of introducing better things, just because it takes a lot of time and hassle.

To be fair there are groups at MS that are not afraid to break backward compatibility for good reasons.

The WPF team is going to no-op the BitmapEffect API since they have introduced real a real HW Shader API, probably for perf reasons. I for one am glad they are doing this, but I wish they had provided drop-in replacements for OuterGlow and remembered to make VisualEffect public for ContainerVisuals. (See - social.msdn.microsoft.com/.../12fbdc6d-0850-4379-b357-bc8a0abc03f3)

API XXX is Dead! Long Lve API XXX!

Web 3 reasons why you should let Google host jQuery for you 链接A引发的思考 YUI Library, YUI Doc, and Github

"You seem to be misinterpreting what I was talking about - I'm saying that we can innovate and improve broken scenarios today because we favor private and non-virtual over public and virtual." - so basically Microsoft can improve things internally, make bugfixes but customers to whom .NET framework is actually targeted at, are stuck with badly designed, "very hard to get it right at the first time" public API? To whom are you producing .NET in a first place?

@Frans: I didn't say he was the primary on NHibernate. He does have other frameworks, you know (Rhino Mocks, he does a lot of Windsor stuff, etc).

HAHAHA

I love it when a certain 'group' of people have all the answers and once again we're back to Microsoft is just stupid and despite and a zillion dollars don't know how to write/design software, but a handful of isolationist who work in silo's with the top 5% of development community know exactly what Microsoft should be doing differently (they're probably former Sun supporters and were telling Sun how to make Java a product that would be used by all).

There's a reason you isolationist are considered that way and your 'groups' are mocked behind your backs - because you live in a fricken Ivory Tower!   Get off your high horse!  All those thousands of people at Microsoft - many who run circles around you in formal education, experience, or both - they don't know what they're doing right?

In fact, why don't you all go to work for DoD for 6 months and come back and tell me if you feel the same about making everything public/internal/overridable for YOUR benifit and YOUR ease of use in YOUR testing framework.  Oh, but wait, you'll probably just tell them they're wrong too right?   Cause everybody has it wrong except for you right?  There's nothing you possibly could be over-zealous about or idealogical about right?   The whole fricken world has a problem and you have all the answers!

Or maybe your just bitter that the company who provides you enough work to make a rather large salary from didn't hire you directly or value some random input you made in the past or turned down your resume.  Since Microsoft has so many core design problems in it's framework, in it's OS, in security, it's browser, why don't you go work for Google in Java - I'm sure everything is public in Java - or no, go do PHP applciations for a living - PHP is 100% testable right?  Or no - go do some Ruby somewhere then.  

Quit your belly aching or go work in a world where these problems don't exist or people want to actually hear your suggestions because the fact is we're sick of hearing it.

@John Who is "We"?  Speak for yourself.

I, for one, am glad "we" have a concerned group of talented people that are willing to voice their concerns with the powers that be.  The fact that many of these people have either authored, or made significant contributions to, projects which are helpful to the community as a whole says a lot about their commitment to the betterment of the .Net development ecosystem.  And if you look at many of those projects, you'll find that they exist to make our jobs easier and make our work more maintainable.  

One of the problems that we’re facing today in the Framework, mainly stemming from the red bits

maybe we should weld the hoods of cars shut because most drivers are not mechanics.

Almost two years ago, to the day, I completely gave up on Silverlight. How do I remember the day so clearly