There's still time to plan a trip to Boston for the BizSpark incubation week, October 5th to 9th.

As Sanjay blogs, you don't need to be in BizSpark to come - it's an event to help startups learn about Windows 7, how it can make your product better, and how to be a successful entrepreneur. You need to be at least interested in building an app that will include touch, sensor and location, the new taskbar or the new ribbon. That covers a lot of ground!

It's a free five day event, though you have to get yourself to Boston and find a place to stay. Up to three people from your firm can attend. Nomination details are on Sanjay's blog, but if you have a BizSpark sponsor you should ask your sponsor to send your nomination to Sanjay.

My firm is a BizSpark network partner. Generally speaking, we sponsor our clients - folks we're mentoring - and not people who are contacting us only to get into BizSpark. If you think completely legal free developer software (Visual Studio Team System, SQL, Windows etc) is just the ticket to get your startup started up, you should definitely look into BizSpark. It's a tremendous opportunity.

Kate

Sasha Goldshtein (not the same as Sasha my MVP lead or for that matter Sasha my nephew - seems some names just follow me around) has another great Windows 7 post and this one features native C++ code for extra fun. It tackles a problem you're likely to run into if you're doing Windows 7 development - what should you use as a toolbar preview if your app has a number of tabbed views? As you probably know IE 8 shows you multiple previews, one for each tab (within reason - I have dozens of tabs open some times and it doesn't show all of them) so you might want the same effect for your application.

The idea is that the app looks like this:

And the thumbnails look like this:




One for each tab. Sasha has provided a pair of blog posts explaining this, and you can download the code from his SkyDrive. Very nice!

Kate

PS: Want to do it in managed code? Well go get the Code Pack then. Tabbed Thumbnails are handled nicely there.

Keyvan Nayyeri knows Visual Studio Extensibility all right. He even wrote a book:

Now he's written a multi-part blog series about extending Visual Studio.

• Part 1 clarifies the difference between an add-in and a package, and acknowledges that there are also other ways of extending Visual Studio (it's actually incredibly extensible in a lot of different ways). It's a nice history review to show us how we got to where we are.
  
• Part 2 is about the IDTExtensibility2 and IDTCommandTarget interfaces. All add-ins implement the first, and those that are on the Tools menu implement the second.
  
• Part 3 turns to packages, which inherit from the abstract class Package (and therefore have plenty of work to do implementing various interfaces.) Keyvan recommends C++ for package development, interestingly enough.
• Part 4 can now talk about the differences between them in some detail. Add-ins are easier, can be written in more languages, but just can't get the same level of integration that a package can. It depends on the functionality you plan to offer your users.
  

Looks like there are more parts to  come ... stay tuned!

Kate

The MVP program is a little unusual. Members are rewarded for what they've already done, and get all the benefits for a membership year even if they do nothing further. Of course, most of us just keep right on doing what we're doing and get awarded for multiple years. Do we do it for the benefits? Probably not. Most of us like doing community "stuff" whether that's speaking, writing, forums, blogging, or whatnot. But the benefits matter - they actually enable us to do the community stuff. We get extra information in the form of access to betas or conversations with product groups. We get access to each other, a treasure trove of information. And we get recognition, which can open doors for speaker selection folks, article selection folks, and so on. I also know as someone who regularly hires developers that "Microsoft MVP" on a resume makes a huge difference for me.

Now my MVP lead, Sasha, has written a pair of articles that summarizes many important things about the program. Part 1 calls us super heroes and Oscar winners (blush) and has some useful links. Part 2 goes into the benefits a bit.

Of course many people want to know how to become an MVP. It's a bit like how to get to Carnegie Hall... practise practise practise. Do the community stuff every chance you get, throw yourself into sharing your knowledge, and when you've been doing it for a while and you know an MVP or two, ask one of them if you think you're at that level yet. If they say yes, ask if they're willing to nominate you. If you think you're really active in the community, but not a single MVP knows you and knows what you've been up to, you haven't been active enough yet. People who don't actively share their knowledge often underestimate what "active" means.

Even if you're not nominated or awarded, I am confident that the community work you do will be its own reward. Approach it like that rather than to earn an award, and you're sure to be happy.

Kate

Scott Hanselman has done quite a few posts on Windows 7 topics already. But now he's done a lollapalooza! He covers:

• The Code⁷ contest - How to get a trip to PDC and $17,777. Not bad eh? Also covered by Yochay.
• XP2Win7 (aka PhotoView) - I've covered it before and I won't repeat the links from that post. Scott includes a gratuitous underwear shot you're going to love.
• Code Pack - you know it almost deserves its own category here on my blog. Like Scott says, a gold mine of samples in both C# and VB.
• 16 bonus links and the "lightweight" parameter for MSDN.

Speaking of the PDC, they've released a bunch more sessions... it's looking very good. I have to pull the trigger soon on a decision about going straight to the PDC from Tech Ed Europe. It's calling me...

What are you waiting for? You need to read Scott's post.

Kate

Here's a recording of a panel at Tech Ed this summer featuring four dear friends of mine: Stephen Forte, Joel Semeniuk, Chris Menegay, and Richard Campbell. The title is "Agile: A Process or an Excuse?" but they don't really answer that question. Instead they talk about what Agile means to them, what to say if people argue about whether you're agile or not, and the role of tooling including Visual Studio Team Systems, sticky notes, really large sticky notes, and Excel spreadsheets. They don't agree on all of it, which makes it a good panel, but the insight is useful. Most interesting to me: Joel and Chris have been in the "I am the guy you are making the software for" role on some internal projects - and found themselves doing everything that your usual contact over in the business unit does when you ask for requirements - forgetting some, being vague, leaving out special cases, and demanding changes because of changes in the business model out in the real world. Users don't do these things because they don't know any better; they do them because that's how life is. An agile approach lets you live in that reality instead of bemoaning the fact that no-one will stick to the things they signed two years ago. I listened on fast speed, but I suggest you only do that if you've spent a lot of time listening to these four because they're pretty fast talkers to begin with, and faster still when they get excited about a topic.

Kate

As you probably know, we're on our way to a new version of the .NET Framework. There's so much that is new in it you could hardly know where to start. I'm just letting the information wash over me in other people's blogs, and trying things out with the beta from time to time. I spotted two related things in the last little while.

First was Improvements to Interop Marshaling in V4: IL Stubs Everywhere on the CLR team blog. The takeaways here are faster performance, consistency between the 32 and 64 bit worlds, and better debugging. Since there is still a lot of native code hiding underneath your managed calls to library functions, everyone cares about the faster performance aspect. Read the post for all the details if interop matters to you the way it matters to me.

Second was COM Interop Gets Much Better in C# 4.0 on DevX. I've always avoided C# for COM interop work because it doesn't do optional parameters, and most COM work is rich in them, especially working with Office, which I used to do quite a lot of. Less casting, no need for PIAs, no more fake values called "missing" or some variant thereof ... it's all good. And here again the magic words "improved performance".

Two small things to note with a non-small impact on your life as a developer.

Kate

Alan Skorkin reminds us that much of what drives current software development process came from the more general study of process for all kinds of work, including manufacturing. When you decide to adopt a particular process, you do so to reach a goal and for that vast majority of businesses, that goal is productivity - more profit per time period. (For a few very small operations, less time period to earn the profit / income sounds far more humane, but is still based on a desire for higher productivity.) Whenever you adopt a process instead of just telling your staff to do whatever you want, it's because you don't think they would be as productive left to their own devices as they would be under the direction of the process.

As Alan points out, there are two very different thoughts behind this basic position. One says that workers are lazy and shiftless. They'd rather chitchat, smoke, or daydream than produce what management wants them to produce. Processes built on this thought are all about measuring and controlling and proving that people have or haven't done what they should have done. The second, christened Theory Y in contrast to the first, which got dubbed Theory X in order to tell the two apart, says that workers are much happier when they know they are productive, and need management to help them achieve productivity as a co-operative goal. Processes built on this thought are full of collaborative work and empowering and the like.

He goes on to draw some specific conclusions about Lean that I will leave aside. I think it's useful to look at the process you work with day to day and ask yourself - is this process founded on Theory X or Theory Y? What image does the management at your firm have of the workers at your firm? Does process control them or support them? Is the motivation for workers assumed to come from inside themselves, or to be imposed by management? No matter what management says about what developers can and can't do, the process you work with will tell you their founding principle. It might be an eye opener to think about it like that.

Kate