Earlier this year we adopted Scrum to manage our releases. Our internship program used it for their project, and then the rest of the development team started adopting some practices — we found it useful enough that we decided to run the 5.0 release as a Scrum project.

I am acting as the Scrum Master, which means that among other things, that I am responsible for generating the burndown chart. Although we have adopted Visual Studio Team System for source control, we are still using FogBugz for bugtracking, so we don’t get the automatic Scrum tools in VSTS. With a little work, I was able to generate what I need. FogCreek publishes the FogBugz schema, so it’s pretty easy to get the data you need. Since they don’t really store historical estimates and elapsed time, you have to get each date’s datapoint for the chart on the actual date, you can’t get previous days (They do store it in comments, but I decided it was not worth parsing the data, since I have to generate the chart every morning anyway).

This query can get the list of open cases for a person and release:

SELECT
  hrsOrigEst,hrsCurrEst,hrsElapsed,
 ixBug,sTitle,sstatus 
FROM bug,person,fixfor,status
WHERE
  bug.ixPersonAssignedTo = person.ixPerson 
  and person.sFullName=? 
  and bug.ixFixFor=fixfor.ixFixFor 
  and bug.ixStatus=status.ixstatus
  and FixFor.sFixFor=?

For burndown charts, you are interested in the total difference between hrsElapsed and hrsCurrEst for active cases. I also track the total hrsCurrEst to see if we’re reestimating cases or if new cases are being added to the sprint.

Even though I don’t parse the automatic comments (BugEvents) for the estimated and elapsed time, I do want to eyeball them (to track down anomalies).  Here is the SQL for that.

SELECT dt, cast(sChanges as varchar(8000)) as changes
FROM bug,bugevent
WHERE
     bug.ixBug = bugevent.ixBug and bug.ixBug=?
ORDER BY dt desc

I probably wouldn’t need to do this if FogBugz would just do sub-totals of Estimates and Elapsed time on their filters (when I group by Owner), but it’s not so bad.

I take this data and copy to Excel and use linear regression on the data to get an idea of how we’re doing on getting the sprint done in time. I generate the chart, and put a copy in our internal wiki, so everyone in the company can see our progress.

In this article, Joel says: “In FogBugz 6 there’s one place where we need to do literally millions of calculations to display a single chart on a single web page” — I’m hoping that that means some kind of release trend chart.

I saw this article on Reddit that applies principles from human-factors design to API design. I think that’s a great idea, but this suggestion sounds weird to me.

Now we could use progressive disclosure to help reduce the complexity of that JButton class: put the expert stuff in an object returned by a getExpertKnobs() method, and the graphics subsystem hooks in an object returned by a getIntegrationHooks() method, and you would be left with a button API that had just a handful of methods—the basic methods we all need.

This brings the number of methods in a button from about 100 to about 10, which sounds great until you try to subclass. Overriding a method that’s in the object returned by the getExpertKnobs method would be a little tricky. It’s likely that you don’t even know the real class of that object because those methods are likely to return references to interfaces, plus the component code is in charge of constructing the objects, so there would have to be a way plug into that too, so that your subclass is constructed. I agree that the interface would be much simpler for most users, but it is much more complex for subclassers.

There’s also the issue of what would be in the expertKnobs object. Some of the methods in JButton that would go in there actually come from JComponent or Component. In fact, as we progressively go down the class hierarchy, we are adding methods into the class that might belong together, which means that there is probably an expertKnobs class for each component class.  But, the getExpertKnobs() method is probably introduced early in the hierarchy — what does it return? Will I have to downcast to get to the button’s expert knobs?

I don’t have a solution — but these issues probably drove the design of JButton more than the idea that they just sloppily added a 100 methods without giving a thought to the complexity of the class.

But the point is taken, and I like the idea of using hard won knowledge from other domains in software design. 

Another recent blog on this topic was Steve Hawley’s Principle of Least Astonishment  essay — the last topic, on layering APIs, has his approach to this problem.

Been looking around WinFX and specifically XAML recently. Not sure I think writing XML is a great way to write a GUI (but billions of web pages clearly prove me wrong). My first impression is that one of the benefits is going to be automated creation of XAML — not from tools, but from our own programs.

It’s been 10 years since HTML was a household word and I still feel like it’s easier to hand write it than use a WYSIWYG tool. I also never really liked using dialog editors. Even good ones like Delphi have too many limitations, especially when it comes to layout. So, I’m not expecting much from the tool support for XAML. But since it’s just a text format, it should be pretty easy to generate from a simpler format (or from models). I’m looking forward to playing around with that idea.

Here are some links I’ve collected on giving presentations. I have been revisiting them lately in preparation for my talk next month.

• Kathy Sierra, in her Creating Passionate Users blog, thinks that we shouldn’t have slides. She also has this crash course on learning theory (with pictures and a workbook). 
• Seth Godin has a free-book called Really Bad PowerPoint. First tip: “No more than six words on a slide. EVER”
• Guy Kawasaki has the 10/20/30 rule of PowerPoint.
• The Beyond Bullets blog has great tips.
• The Zen master of presentations, Steve Jobs, vs. Bill Gates.

C++ (and Cocoa) unit testing is built into XCode on OSX. I am writing an application right now that I plan to port to Windows. When I wanted to see how portable my code was, I decided to get all of the unit tests passed on Windows.

Unfortunately, XCode does not use CppUnit, which is already portable. Here is some code I wrote that you can use to run your XCode generated unit tests on Windows.

Despite his rants against C++, Stevey’s Drunken Blog Rants, is one of my favorite new blogs. Actually, since it hasn’t been updated in about nine months, and was written mostly in 2004, it’s not really new. It was rediscovered by social bookmarking sites (I found it on reddit.com). I was reminded of it while thinking about resuscitating this site.

There are a lot of great articles, but this one about server-side service software is one of my favorites (given that I’ve spent a lot of time thinking about the subject). Another great article on this topic is Paul Graham’s The Other Road Ahead.

The old .NET SAPs is rechristened under the name: Western Mass .NET Users Group  (and a spiffy new website). Tomorrow’s meeting topic is XML.

Speaking of XML, I saw this recently: Don’t Invent XML Languages by Tim Bray. In addition to pointing to this great list of XML Languages, he introduces “The Big Five” XML Languages and where they should be used.

Suppose you’ve got an application where a markup language would be handy, and you’re wisely resisting the temptation to build your own. What are you going to do, then?

The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom.

I was talking to a developer friend today about developers who don’t get the importance of communication. Look through any want-ads for developers and right after the alphabet soup of technologies you have to know is the same requirement—must have “excellent written and verbal communication skills”. You’d be hard pressed to find a programmer job without those requirements.

But, expressing yourself clearly is only half of communication. The more important aspect is listening to and understanding other people. This is what separates good and great developers. And the most important skill in understanding is empathy—not only understanding someone, but being able to be them.

To be a successful developer, you have to learn more than just the software aspect of your business. Developers who understand this are more valuable and valued more. If you want to do this effectively, you have to think like a saleperson, a marketer, a CEO, your customers, the press, etc. You have to think like them because they aren’t all going to try to think like you (but if they’re going to try, by all means, help them).

Another part of empathy is thinking about how they will interpret your words. For instance, avoid rhetorical tics like “think about it” and “you’re not seeing the big picture”. Not only are they annoying, but it puts people on the defensive.

If you understand—not only what someone is saying, but why—you’ll have a much better chance of expressing yourself. So, the next time you have a communication gap with a non-developer, stop talking and ask yourself how much you even understand about them.