CoolBeans: From College to Industry

Boolean Shape Operations in PowerPoint

Chris Becker — Wed, 24 Feb 2010 19:10:00 GMT

In case you didn’t see over on the PowerPoint Team Blog, there’s an entry on my awesome feature addition to PowerPoint 2010!

Adding this feature to the product was a bit of challenge as we didn’t originally plan to do it. But we found most of the code we would need was already available and in use the product elsewhere. A few bits of code to bridge some UI to the core path operation results in some cool new abilities for advanced PowerPoint users.

1+1=1.5: How estimating coding time breaks math

Chris Becker — Wed, 03 Feb 2010 07:59:00 GMT

I always hate providing a SWAG [guess] on how long something will take. Predicting how much time I will work on something is never a good indicator on when the item will be finished.

A talent a good dev will have is to take two 1 week features and finish them in 1.5 weeks. It may seem like black magic, but most people don't work on everything serially. You interleave work between tasks; coding on one while the other is still compiling. Washing your clothes will take 1 hour, but washing two loads benefits from usage of the washer and drier at the same time in the middle.

This model of “shorter done together” seems to go against the grain of traditional software planning. You can’t put it into a spreadsheet and sum it together, because the total time spent will end up being less than the sum.

In the end, given 12 weeks and 5 features, as long as all 5 are done at the end of 12 weeks who should care? Turns out managers tend to care because they need to measure everyone’s time the same way to get an accurate picture where their team is.

Plugging into this model is something that’s not easy to do and requires some patients on both ends. A good dev will know how to emulate what their manager wants to hear, and a good a manager will be able to interpret their report’s work style in a way which plugs in to their tacking methods.

Now can someone teach me to be a good dev given the above? I always seem to frustrate someone with my “trust me it’ll just get done” attitude problem.

Callstack to the Rescue!

Chris Becker — Wed, 07 Oct 2009 06:33:00 GMT

Been busy getting Office14 out the door. One thing keeping me busy is crashes buckets from Office 2007. When an application crashes, it will send information back as to where the program was when it crashed.

These crashes are analyzed and grouped together into similar “buckets”. We take the top buckets and try to determine what went wrong so we can fix them.

It pays to be good with a debugger and know assembly code here since all you have is registers, code and some memory at the time of a crash.

But what can be even more helpful is if someone else has already found a way to hit this crash. It’s 100x more useful to have repro steps which the same crash than it is to just have a dump. You can use a debug build (sometimes), you can use break points, you can change code to see how it affects the crash and later you can write automation to make sure it doesn’t come back!

How do you find these mythical repro steps? By searching the bug database for similar callstacks. If a tester has found a crash, ideally they also logged the callstack. If the callstack is similar to the dump file’s, it’s likely the same issue.

A Punted Bug

Two years ago, before Office 2007 shipped, we were all testing it trying to find a recall class problem. I came across a crash that involved SmartArt, text fields, multiple slides and undo/redo. Given the very convoluted way the crash reproed, we decided it wasn’t worth investigating and punted the bug.

Fast forward to today and we have a number of crashes in SmartArt that we don’t know what’s causing them. Turns out, people are hitting the same crash I found two years ago, although likely with simpler steps.

If I hadn’t copied the callstack into the bug, we may never have found out why this was happening.

Thank you, two years past self.

"How do I fix more bugs?"

Chris Becker — Wed, 10 Jun 2009 08:58:00 GMT

I was asked “How do I fix more bugs?”

The answer is to own buggier areas! Devs who own buggy areas (best when not through some fault of their own) will resolve more bugs because more bugs will be incoming.

Another is to file bugs and fix them. Not dumb bugs, but real bugs. Sometimes only devs can see the problems while looking at the code. If you feel bad filing and fixing your own bugs, assign them to PM first to prioritize.

More importantly, seek out buggy areas. This shows initiative and desire to help ship the product. If instead you wait until you run out of bugs and someone assigns you something else to do, it’s less impressive. “He fixed it, but only after I gave it to him”.

Of course, if the area remains buggy, you haven’t helped yourself. If bugs keep incoming, it could be the feature needs to be scoped again. This usually means talking with PM and test about cutting or stripping down features. Sometimes, a small change in spec cuts off an entire area of bugs. This is just as good as fixing a lot of bugs, since you identified a key area that if cut would dramatically reduce bug counts.

One such example would be supporting rotation of entire SmartArt diagrams. It’s a simple user scenario, but it affects every aspect of editing the diagram plus you need to deal with the content pane when the diagram is rotated and the list will go on and on. In the end, not supporting rotation simplifies the entire implementation and cuts off a whole chain of bugs. (Today of course you can just ungroup it and rotate the group if you really want).

Better bug ordering means better fix rate

While there are many bug priorities, they are rarely stacked in such a way that will lead to the most amount of bug fixing possible. I’ve found fixing everything strictly in priority order will get you stuck on the hard bugs the entire cycle.

Instead, I always have one machine used to fix hard, important bugs and another free to fix easy, “fun” bugs. This gets rid of lower priority fit and finish issues that we wouldn’t normally get to if we didn’t just fix them. It also gives me a break from working on any particular monotonous and difficult bug which usually leads to better a fix anyway as I’ve had more time to think about it.

Fixing lower priority bugs in between higher ones prevents a backlog of stuff to work on which PMs will have to go through and make cuts of. You can’t save every bug and many bugs should be punted, but getting rid of the easy ones means less things PMs have to cut. Plus it makes you look good with a higher resolve rate and less bugs assigned to you.

Negative space

Additionally, the most severe bugs from the user’s perspective are not always the most important to fix first. Many bugs which come to be known as “Work Items” in Office need a lot of ground level support to really fix. It’s not enough to just fix the symptom of a particular bug, there tends to be a larger cause that needs addressing to prevent future bugs.

These are probably the most important things for devs to identify since no one else really knows that the future holds many more problems if the area doesn’t get looked at.

And that’s probably the most valuable thing to put in a review, but the hardest to prove: that you prevented downfall of the entire feature because you reworked the area. If you hadn’t done it, you’d be drowning in bugs, but because you did it there’s no proof there was ever a problem. It’s productivity in “negative space”.

One way to show this is to show how bugs in the area tended to go down after your fix. Another is to show a certain class of bugs that kept coming up over and over but stopped after your fix.

Either way, hammer it home during reviews. Every manager should know exactly how much awesomer the product is now that you’ve graced it with your presence.

Airports and Cylons

Chris Becker — Mon, 25 May 2009 06:03:00 GMT

I’ve noticed one thing in my travels through airports: power is king.

I routinely bring a laptop and MP3 player stocked with music and movies to watch during the flight but I always over prepare incase I get stuck waiting.

But all of this is for naught if you can’t find an outlet.

As I sit in DIA waiting another 3 hours for my flight, I’ve observed huddles of people, clutching to floor space near coveted outlets. Wires are strung across open space from phone booths to chairs 2 feet away. The most ambitious sit next to a computer booth next to someone else as they charge their cell phone on the one outlet the occupier isn’t using.

When it snows DIA must turn into a modern day Lord of the Flies as people degenerate into amp hoarding gangs of travelers, fending off other’s drained cellphones and computers. Entire tribes die as a circuit breaker trips and knocks out power to gate A25, leading to the remaining mounting an attack on Concourse B.

Maybe the smartest thing to pack is a powerstrip. It would give me absolute power converting two outlets into 6 or more! Or at least let me leech off an outlet someone else has already claimed.

As for today, it turns out Midwest is done with flights and their gates are nearly abandoned. A sweet spot next to a column with two untouched outlets allows me to write blog posts and watch Battlestar Galactica, saving me from certain social doom if my friends were to find out on Monday that I’d never seen the show.

If they really need a Cylon detector, why can’t they just use X-rays and metal detectors? The writers clearly never spent 6 hours in an airport.

Best SmartArt Feature Ever!

Chris Becker — Tue, 05 May 2009 08:29:00 GMT

Like SmartArt but wish there was more flexibility in customizing its shapes? We added just such a feature in Office 2007 SP2 which gives you the ability to ungroup a given diagram in PowerPoint.

Just right click the border of a top level diagram and choose “Ungroup”:

Below are the original diagram on the left and the resulting shape group on the right:

Now that the diagram is a group, you can manipulate the shapes individually which means they won't affect the size or position of other shapes in the diagram (the "smartness" of SmartArt will be gone). This also includes dragging the shapes outside of the original border, editing as freeform and adding text to all diagram shapes. Finally it allows for more tailored animations as each shape can now be animated individually in the Custom Animation pane (if you ungroup the resulting group first).

Why am I so excited about this feature? Because it was an idea I had after Office 2007 shipped. I convinced our PMs to create a spec for it, and it turned out to be so useful during our testing that we back ported it from Office 14 into Office 2007 SP2! Quite a rare event having a feature thought up by a developer making its way into a previous version of Office.

Being able to demonstrate a nearly fully functional prototyped also helped seal the deal. Many features are great ideas on paper, but run into trouble when we try to implement them. Doing a solid prototype proves the feature isn't down right impossible. You can also send the feature to a tester to bang on for a while to see if any showstopper bugs rear their heads.

So thanks to a bunch of people's hard work, we shipped the best and what will surely be the most beloved SmartArt feature of all time (except for all those still to come).

Office 2007 SP2!

Chris Becker — Wed, 29 Apr 2009 03:06:00 GMT

A quick note: you can now download Office 2007 SP2 or read more about it here. There are some pretty sweet things in this update that I got to work on; I'll touch on "...more control over the appearance of SmartArt graphics" in a later post.

Productivity in the Car

Chris Becker — Tue, 21 Apr 2009 09:03:00 GMT

Practically every book I see advertised on The Daily Show I've gotten at my local library. But this sometimes leaves me with tons of books piled up to read. So I started getting the books on CD when I can and using the CD changer in my car to queue up 6 CDs at once. I've since been able to "read" several books just by going to and from work, time that was in the past spent focused on the slow driver in front of me or lamenting the bug I was going to have to fix that morning.

When Bugs Knock on Your Door

Chris Becker — Sun, 18 Jan 2009 02:36:00 GMT

I bought a place back in September and had just this week gotten things mostly settled. Then today some people knocked on my door. I opened, and there were 3 men, 2 women and baby. It sounded like the makings of some kind of movie sequel, but not the kind I wanted to be in the center of.

They said they had called earlier and wanted to see the place.

Well that’s interesting, I thought. For one, I'm under the age of 30 and so have never had an actual land line telephone for someone to call me on. For another, this must be the sign of a wet wear malfunction since I had no recollection of putting the place up for sale.

They showed me the sheet which had my address and picture of the place on it. I silently noted how the "asking price" was $15,000 more than what I paid. I informed them I had no interest in this many roommates and that they try some of the other places down the street.

I went back to my room and hopped on the source of all true information: the Internet. But it failed, or at least lied, since Realtor.com and Zillow.com both show the place as sold at the price I paid.

But the question still picks at my brain. What database hasn’t been notified that the house has sold? And what program (or person) increased the listing price?

I think a human error is more likely than a computer bug in this case, but the consequences of a computer bug would have had the same effect: people showing up at my door wondering why there was still furniture in the place. A software error manifesting itself in the physical world, now that’s a creepy thought.

Which is why I’m very glad I don’t work in any kind of mapping software, where that mistake in code makes the computer call out “turn left” and suddenly you’re not in Kansas anymore. We don’t need walking metal later to be governors with machine guns from the future to kill us all, just write a virus that invades MapQuest and let people do themselves in.

Oh, and who the hell did they talk to?

Today’s Bug is Brought to You by “Don’t Mix C and C++”

Chris Becker — Thu, 08 Jan 2009 01:55:00 GMT

Take this for example:

#include <iostream>

#include <iomanip>

class Storage

{

public:

Storage() : m_val( -1 ) {}

int m_val;

};

class Holder

{

public:

Holder() : m_double( 50000 ) {}

union

{

double m_double;

struct

{

Storage m_storage;

int m_id;

};

int _tmain(int argc, _TCHAR* argv[])

{

TestClass t;

std::cout << std::setprecision(20) << t.m_double;

return 0;

}

So where does 50000.03125 come from? It’s nowhere in the code.

It comes from mixing the 50000 passed into m_double and the constructor for Storage later assigning m_val to be -1.

But why? What’s the proper order things get initialized in a union? What if I have two classes each which have their own constructors, which one gets called since they both occupy the same memory?

The C++ standard says thusly:

An object of a class with a non-trivial constructor (12.1), a non-trivial copy constructor (12.8), a non-trivial destructor (12.4), or a non-trivial copy assignment operator (13.5.3, 12.8) cannot be a member of a union, nor can an array of such objects.

So, the above should result in a compiler error, but it doesn’t as of VC++ 9. In fact, if you change the code to have a named struct:

union

{

double m_double;

struct MyStruct

{

Storage m_storage;

int m_id;

};

MyStruct m_struct;

};

You get the correct C2620 error:

error C2620: member 'Holder::m_struct' of union 'Holder::<unnamed-tag>' has user-defined constructor or non-trivial default constructor

A similar coding error has existed in the Office code base for a while, but went undetected because of how the memory corruption occurs. Since 50000 becomes 50000.03125, nobody noticed that the sub-pixel rendering of certain shapes was slightly incorrect until a separate, seemingly unrelated assert kept popping up saying two numbers it expected to be equal were not. If the corruption had occurred in an integer, or the storage class and m_id were in a different order or the compiler had correctly shown an error on this or the original developer had used a named struct, the problem would have been easily identified. But since all these things didn't happen, we have small deviations in the original double value.

What did happen was good test automation, which routinely hit the assertion and we were able to trace the root cause of several bugs and fix the problem.