As noted in posts I made back in March (Groundhog Day at MSDN) and in April (Déjà Vu All Over Again), I'm trying to tackle the unenviable task of addressing the growing complexity of content on MSDN. To get a glimpse of what MSDN used to be like when I first got to Microsoft, I used the Internet Archive's Wayback Machine. MSDN Online in April 1999 was a bit simpler than it is today. The Visual Studio site in 1999 had content for Y2K, boasted integration with Rational Suite, and linked to the new Visual Studio Solutions Center containing Windows DNA sample applications.
In the intervening years, MSDN's rapid growth mirrored the increasing complexity of developer tools, platforms, and technologies that lead us to where we are today. Through a combination of innovation, acquisition and evolution, Visual Studio expanded to the broader software development team, new platforms emerged (.NET, Dynamics, XNA, Windows Embedded, and numerous server products), languages were created (C#, J#, etc.), and technologies were added to the developers arsenal (WPF, WF, WCF, etc.). For those developers who were along for the ride, you're probably still waiting to catch your breath.
At times I think the "Curse of Knowledge" (originally described in The Curse of Knowledge in Economic Settings: An Experimental Analysis, but recently made popular by the Heath brothers in Made to Stick: Why Some Ideas Survive and Others Die - which is an awesome read) has kept us from doing a better job of managing the complexity of it all and making the Microsoft developer story accessible to more people. Outside of sites on MSDN like the Beginner Developer Learning Center, do we really know what it's like to be a beginning developer these days?
In The Laws of Simplicity (Simplicity: Design, Technology, Business, Life) (another excellent read), John Maeda writes Zen-like (at times I caught my mental voice sounding like I was speaking to a young Kwai Chang Caine) about the 10 Laws for achieving simplicity. Reflecting on MSDN, I can see various ways of applying many of these laws to simplify the MSDN experience. Maeda structured the Laws such that "the successive set of three Laws (1 to 3, 4 to 6, and 7 to 9) correspond to increasingly complicated conditions of simplicity."
- Reduce - the simplest method whereby you thoughtfully eliminate what's not needed. I know a lot of people would argue that this is sorely needed on MSDN.
- Organize - develop a system that makes more look like less. The new MSDN UI helps here, and I have a specific idea to organize MSDN to help reduce complexity.
- Time - anytime you make something faster, it feels simpler. Search is probably the easiest answer here.
- Learn - knowledge makes stuff seem simpler, which can lead to the Curse of Knowledge. Learning to use MSDN is probably the most we should ask.
- Differences - simplicity and complexity are somewhat relative; without one, the other is less obvious. I think the complexity of the developer landscape is sufficient enough that we need not mirror it with MSDN.
- Context - to understand where you are in the larger scheme of things. The idea I hinted at in Law 2 addresses this, too.
- Emotion - when emotion matters, add complexity if needed to achieve it; if form follows function, emotion follows form.
- Trust - the more the system thinks for you, trust it so you need to think less. To me, the notion of personalization tries to achieve complexity by letting the system manage complexity for you, but leapfrogs some of the simpler means of achieving simplicity.
- Failure - the one I fear with this endeavor: that some things just can't be made simpler.
- The One - subtracting the obvious and adding the meaningful. Of course, the Curse of Knowledge can derail this; what's obvious to the expert, or seemingly meaningful, may not be to the novice.
Today, MSDN is largely a collection of sibling developer centers that sprung up over the years as new products, technologies, and platforms were added to the Microsoft developer story. One fundamental idea I have to simplify MSDN is to Organize these developer centers in such a way that it also provides Context based on the type of software development. In addition, I think there are some areas of MSDN that are core to all (well, almost all) software development. Conceptually, here's the layer of organization I'd like to insert between the MSDN home page and the vast collection of developer centers and other resources on MSDN (yes, I know this needs more explanation - I'm afflicted by the Curse of Knowledge, too):
Interestingly enough, the Beginner Developer Learning Center does this on a smaller scale with entry points for Web, Windows, and Game Development. Something you may have noticed as missing from this illustration is .NET. To me, .NET is increasingly ubiquitous in the Microsoft developer story, which is why I'd place it in the category of Core Development Technologies.