Where Bugs Really Go To Die, Your Product Documentation

Saturday, August 3, 2013 – 3:09 AM

From somewhere not so agile and written from a documentation writer’s perspective.

We’ve all heard this story…

Too many bugs to fix for the Beta 1 milestone? Punt them to Beta 2. Of course during the Beta 2 milestone you fix some of the high priority bugs from Beta 1 but find more bugs in Beta 2. Still too many bugs? Punt them to the Final Release milestone. Fix some more bugs, find some more bugs. Hopefully your team is fixing them fasted than they are finding them so things slowly improve. But now there’s nowhere to go.

So you start pushing the bugs that can’t be fixed to documentation. It’s so easy. All you have to say is “we’ll just document that”. Say it enough times and “No Bugs!” simple.

This has a couple of unappreciated and unintended consequences…

Firstly this makes the documentation writer’s job much harder. Explaining each of those weird little caveats takes far more effort than you might imagine. Good writers are trying to show your product in the best possible light. That’s hard when they’re trying to cover up all the defects.

Secondly you end up with lengthier hard to read product documentation full of caveats and additional information describing the weird product behavior all those bugs caused.  This doesn’t really change anything. “Fix” or “Don’t Fix”. All postponing to the next milestone or release does is drive unseen work downstream and adds risk to the project as some bugs may be hiding large work items. For the most part get the bug fixed immediately; this iteration or the next. This has the added benefit of not cluttering up your bug tracking system with postponed bugs. I’ve seen bug tracking systems with thousands of bugs that just hung around, they were never going to get fixed. Rank bugs alongside new product features. Rank them during iteration planning. Get the Product Owner to choose between new work and fixing defects.

Use your writer’s skills. Really you want a writer on the team from really early in the project. Writers, like good testers, can give you a lot of feedback on how usable your product is. If your writer is telling you something is going to be hard to explain to users then it’s fair to think it’s going to be hard for users to understand.

Quantify your bug debt. Use historical fix rates or estimate them in iteration planning. The Product Owner may be tempted to try and push lots of small bugs out by prioritizing features ahead of them. One way to get them thinking is to tell them that if they wanted to ship today and didn’t want to ship with any of those bugs then it’ll take another X days to really be done.

Don’t be afraid to cut. Don’t integrate bug ridden features and don’t be afraid to cut features that have unexpected bugs. It’s far easier to tell users that something isn’t supported than it is to guide them through a series of word around steps to get a badly written feature to work.

C++ AMP Debugger and WARP Accelerator Support on Windows 7

Thursday, March 28, 2013 – 9:25 PM

Debugging and WARP accelerator support is now available on Windows 7 and Windows Server 2008 RC2 with the Platform Update for Windows 7. The following blog posts outline how to use these:

This is great news for developers who are on Windows 7 and want to either develop on it or have their application fall back to WARP on customers’ Windows 7 machines without a C++ AMP capable GPU.

I lobbied the product team on this one as lots of readers asked both myself and Kate about it. Looks like they and the DirectX team got it done. Really happy to see that it’s actually happened and within six months of the Visual Studio 2012 release.

In other news NVidia have added support for hardware debugging. You can read about how to enable this on the C++ AMP team’s blog too:

Things are really looking up for GPU development on Windows.

GPU Technology Conference 2013

Thursday, March 21, 2013 – 5:01 PM

A few years ago I went to the NVidia GPU Technology Conference. I promised myself I’d be back in a few years and speak at it. Well’ it’s 2013 and here I am! The week has been really fun; lots of good talks, especially the keynotes. I also seem to be hanging around with the OpenCL crowd who turn out to be a lot of fun.

An Overview of Accelerated Parallelism with C++ AMP

S3317_AdeMiller“C++ AMP is Microsoft’s GPU programming technology. This presentation, by one of the authors of "C++ AMP: Accelerated Massive Parallelism with Microsoft Visual C++" (MSPress), gives an overview of C++ AMP’s features. The presentation will introduce C++ AMP’s algorithms and containers programming model and its two minor additions to the C++ language. By programming against a hardware agnostic data parallel accelerator model, rather than specific hardware, developers can future proof their applications to run on a variety of data parallel hardware. Several C++ AMP examples will be demonstrated, showing the array and array_view container types and the parallel_for_each algorithm. The examples will be extended so show how C++ AMP code can be optimized and then used with the Parallel Patterns Library on the CPU to take advantage of multiple GPUs and achieve further performance improvements with braided parallelism.”

Now the whole speaking thing is out the way it’s time to get back to the real thing, implementing radix sort for the C++ AMP Algorithms Library. Something to do on the flight home.

Writing A Programming Book

Wednesday, January 9, 2013 – 12:30 AM

6206Really you should do yourself a huge favor. The next time one of your friends suggests you write a book, just ignore them. That’ll also save you the onerous task of reading the rest of this post.

Still reading? Oh dear. Well I guess I feel compelled to inflict some well meant advice. This is based on collaborating on three books in the last few years. I’ve also written numerous technical papers, a PhD thesis (i.e. another book) and several published articles. Glutton for punishment, that’s me.

1) Understand what you’re writing about

If you’re contemplating writing a technical book on something, then you probably already consider yourself to be something of an expert. Writing a book is a great opportunity to round out all the dark corners of the topic and understand it completely. There’s a lot to be said for learning something by forcing yourself to explain it to someone else. This is not an invitation to decide to write a book something as you’re learning it. The result will read like a Presidential candidates manifesto but with fewer outright lies.

Even if you know the subject cold that doesn’t mean you understand what explaining it to others is going to entail. When you assemble the outline (see #3) do it with an eye to identifying topics that will be harder to explain or less familiar to your audience (see #2).

Read the rest of this entry »

I’m Speaking at The GPU Technology Conference

Friday, December 14, 2012 – 7:11 PM

So I got my talk accepted to GTC 2013. It runs from March 18-21 at the San Jose McEnery Convention Center. I went a couple of years ago and really enjoyed it. At the time I made it a goal to come back as a speaker and now here we are! Hope next year’s is even better.

image

S3317
An Overview of Accelerated Parallelism with C++ AMP

Ade Miller (Principal Architect , Microsoft Corporation)

C++ AMP is Microsoft’s GPU programming technology. This presentation, by one of the authors of "C++ AMP: Accelerated Massive Parallelism with Microsoft Visual C++" (MSPress), gives an overview of C++ AMP’s features. The presentation will introduce C++ AMP’s algorithms and containers programming model and its two minor additions to the C++ language. By programming against a hardware agnostic data parallel accelerator model, rather than specific hardware, developers can future proof their applications to run on a variety of data parallel hardware. Several C++ AMP examples will be demonstrated, showing the array and array_view container types and the parallel_for_each algorithm. The examples will be extended so show how C++ AMP code can be optimized and then used with the Parallel Patterns Library on the CPU to take advantage of multiple GPUs and achieve further performance improvements with braided parallelism.

Session Level: All
Session Type: Talk
Topic Areas: Development Tools & Libraries, Parallel Programming Languages & Compilers