Eric Lippert an SDE somewhere in the VS05 effort describes ZBB:
“Zero Bug Bounce (ZBB) day is the day on which, even for a single instant, every bug in the database is either (a) postponable to the next release/version, (b) fresh — discovered within the last 48 hours, or (c) not fixable right now.”
My question is, why not count the bugs in the last 48 hours? Are those somehow less valid than the bugs found 49 hours ago? And what’s with 48 hours itself? Why not 36? Or 72? Pathetic product team wannabes wanna know!
Business Desktop Deployment Framework: all you’d ever want to know about deploying Windows in an enterprise so that you’ve got a suitable platform on which to deploy smart client applications
Since the Smart Client DevCenter now has a Content Strategist (me), expect to see regular releases of articles and samples exploring smart client-related technologies, including but not limited to Windows Forms, the Compact Framework and Visual Studio Tools for Office.
And don’t hesitate to send Jonathan or me your complaints and suggestions. We don’t put this site up for our health, you know; we do it for you!
I love the idea of outsourcing to rural parts of the country because a) I like keeping jobs in the US if possible (although I’m not a protectionist by any stretch of the imagination), b) it gives the under-employed more choices and c) it’s another step toward my dream employment environment.
I see a future where people are listed like books on Amazon with ratings, reviews, descriptions (aka resumes), prices and availability, to be placed into a shopping cart to form ad hoc project teams based on the needs of the project and not on the locale of the participant or something as restrictive as “employer.” I admit that I this article is only a small step and may not even be in the direction I’m hoping for, but as I’d like to live in a rural area (central Oregon) and still get to do interesting work at reasonable pay, I’m more than happy to read into things.
I really like giving short little vignettes imagining an audience; I didn’t think I would
The preparation for recording a screen demo is the same as a real demo, i.e. I want to make sure I know what I’m going to demo before I do it
The preparation does not include lighting or another person to run a camera or a microphone, which means that I can do it on a whim at 5am on a Saturday morning
My built-in mic at normal speaking volume works great
Capturing a particular screen doesn’t work very well because I’m likely to move between windows without knowing that I will ahead of time. Instead, I should capture a region of the screen, ideally something not too large so that it fits well in a video window
Medium quality may not be good enough. I did 13 minutes at medium quality, which resulted in a 3MB file and good audio, but the screen itself was nearly unreadable. Maybe the screen itself was too big?
Stop other apps before capturing a screen, otherwise you’re bound to get slowdowns in the capture, particularly in the audio
Talking in my kitchen at normal volume for 13 minutes will waken my wife (sorry, sweetie)
So, while I wasn’t happy with the results, I’m very jazzed about the medium. Expect to see more.
“Bill Wagner takes us through using the more extensible Updater Application Block to automatically install and maintain applications. He also discusses the importance of validation and how to use post processing commands.”
I've been reading each of the Software Factories articles with great interest. Part 1 and part 2 did a particularly good job describing the elements of the problem space, I thought. However, when I get to part 3, I was ready to see a solution. Instead what I got was a long abstract piece defining the bits of what makes up a software factory. This is the kind of thing I'd be ready to read after I was shown a concrete example or two of working, running software factories. Do other people like reading these long, abstract articles? I find them tedious unless they're filling in and generalizing the details of something that I've already got a handle on.
