@Brad – thanks for your kind words, and for your very rich coffee – what a nice way to wake up in the morning 🙂

The program’s code size was not small (close to 80K source-code lines in ~600 files), so it took me some time to understand what’s going on and what’s relevant (only ~5K lines of code in perhaps a dozen files, it turns out). It then took me some time to figure out how to improve performance, and finally to fix all the code behind the numerous GUI controls so that they work correctly with the new graphics (i.e., now we only have a single large line handle rather than multiple separate handles, so wherever there is a reference to a particular line segment the code needed to be changed). Finally, testing took another hour or two. All-in all I’d say that I invested perhaps a full workday on this. I did get some specific guidance about things that were particularly bothersome for the team (both in terms of performance and functionality), so I focused mainly on those, but along the way I saw other parts that could be improved for speed or functionality and I improved them as well. There were also a few functional bugs that I discovered during my work, and I fixed them too. All these extra fixes took perhaps another half a day. So all in all this specific GUI took me about 15 workhours, but this included both functional and speedup improvements.

I think that it’s difficult to use these times as benchmarks, because as I said the code was large and complex, and I needed some time to get up to speed (pun intended) with it. It’s quite likely that programmers who create their program would be able to do things faster, since they’d already have all the fine details in their mind. Also, it takes some time (and perhaps a bit of nerve and self-confidence) to understand that another person’s code has a functional bug and should behave differently than the way it actually does.

I just finished reading Code Complete 2 (highly recommended!), which discusses among other things the huge variance in productivity among programmers. With that theme in mind, I’m sure some of your other readers may be interested as well in the following questions:

May I ask you please to give some color on how long it took you to assess the indicated problems? Your post gives the impression that the Harvard team’s guidance may have been non-specific (“This is too slow, please speed up wherever you can”). Was that the case? Did you just dig in then and start methodically going through things using your own judgment? Or did the team provide an itemized list of concerns? If it’s not inappropriate to ask please, about how many hours of work went into each of these stages, to the extent they were distinct: problem assessment, code improvements, and QA validation?

I believe your answers will be helpful to the Matlab community at large. It’s always good to have benchmark impressions in mind. In this case, what can a world-class expert accomplish? Thanks in advance.