This is a call for beta testers interested in trying out our new version control product: Kiln (http://www.kilnhg.com/). Mercurial is the version control system under the hood, so if you've got FogBugz and wanted to try out a DVCS, this is a great opportunity. If you just want to experience the awesomeness of version control, code review, and bug tracking all working together seamlessly, this is a great opportunity.

I have to mention that this is a beta. There will be some bugs during installation, and possibly after. The good news is that Kiln has been running for several months and hosting production code for a bunch of people in the On Demand environment. We think the risk is pretty low, but as software developers you know there is no way for us to guarantee that there won't be bugs.

We are specifically looking for licensed (install it on your server) testers, although you can use the same form if you're a FogBugz on Demand customer (the more the merrier!):

https://shop.fogcreek.com/beta-kiln/

Licensed Kiln will only run on Windows 2003/2008 Server with SQL Server 2005/2008/2008 Express. Folks running other operating systems or database servers are out of luck for the time being.

ONE MORE THING: This release also introduces a new version of FogBugz. There have been a few UI changes to support having FogBugz integrate with other applications. If you don't want to test Kiln, but would be willing to test the new version of FogBugz, send me an email to jason (at) fogcreek (dot) com.

Manicwave Productions has just released Tickets (v1.0), a Mac OS X client for FogBugz. It provides an elegant Cocoa interface for fast, easy case entry.  You can also attach screenshots, and use an integrated status bar menu to browse the history of recently created cases.  Tickets even provides excellent features for power users, including support for Global Hotkeys and Applescript automation.

Tickets requires Mac OS X 10.6+, and is available for purchase on the Manicwave website.

We've just started sending out an email newsletter to Fog Creek customers who are interested in:

• Classic articles on software development and project management
• Release announcements concerning offerings from Fog Creek and its partners
• Helpful how-to guides for FogBugz and other Fog Creek products such as Kiln and StackExchange
  
• Links to new posts appearing on this blog
  

Sign up here: http://www.fogcreek.com/FogBugz/Newsletter.aspx

And check out the web-based copy of Issue #1 (sent out this week) right here: http://media.fogcreek.com/newsletter/2010/Newsletter1.html

Newsletters will go out roughly twice a month. Feel free to forward them along to friends and coworkers!

The FogBugz Team is pleased to invite another product into our partner ecosystem: SnapABug Visual Customer Support.

SnapABug allows website designers to quickly and easily embed a small (but powerful) "Help" widget in their site. When a user of the site experiences a problem and clicks the control, they're presented with a small form that gathers their email address, a short description of the problem, and (optionally) a screenshot of what they're seeing on the website.

Here's the best part: if you use FogBugz to track your customer issues (and honestly, why wouldn't you), you can configure SnapABug to automatically generate a FogBugz case that contains all the data entered into the SnapABug form, with screenshot attached.  It's never been so easy to run a responsive help desk for your customers: instead of spending valuable time determining the particulars of the problem, you can use SnapABug to quickly discover, reproduce and diagnose the bugs getting in the way of your users' happiness.

Learn more about SnapABug and start a free trial at http://www.snapabug.com/.

We've had a recent problem with potential and current customers finding old and outdated information on our discussion boards.  One option we had was to archive the discussion board each time we have a new release (probably the best idea), but we didn't do that unfortunately.  Our other option is to just erase all old topics from our database (not nice to Google and we don't want people to think we're hiding our warts). The third option is to leave the content up and figure out a way to really make sure people know the info they are about to see no longer applies to our current product (probably).  It took me about ten minutes to come up with a solution using the BugMonkey plugin, which allows you to insert arbitrary JavaScript and CSS into your FogBugz site.

You can see an example in this post about FogBugz 4.0.

You can view the code I used for the lightbox effect.

You can also download and view the javascript: sample.js (880.00 bytes)

In doing this I realized it would helpful if there was a systematic id system for text portions of the page (in this case, it was difficult for me to get the date of the topic, since I didn't want it to be applied to current topics). Definitely something to think about in the future...

FogBugz users who develop in the Eclipse IDE should have a serious look at Foglyn, an Eclipse plugin by Peter Štibraný that allows you to view, organize, and manipulate your FogBugz cases without ever leaving the IDE. 

Foglyn smartly builds upon the Mylyn task management interface to make it perfect for use with FogBugz:

• Easily run a search query returning a list of cases you care about, and view subcases in outline format
• Edit cases using a powerful form interface
• Embed hyperlinks to FogBugz cases directly in source code
• Easily tell FogBugz what cases you're working on by activating them right from the IDE

Eclipse users can visit www.foglyn.com to download the plugin and try it free for 45 days.

In this video, Dan and Babak talk about how we got to FogBugz 7. 

(Click to watch the large version on YouTube).

We recently launched the FogBugz Knowledge Exchange, a powerful Q&A resource for anyone who wants to learn, teach or discuss FogBugz.  It was (quickly and easily) built upon the Fog Creek StackExchange platform, and has been continuously gathering users and helpful content since the moment it hit the Interwebs.  It's no surprise to see that Support Lead Rich Armstrong is currently at the top of the reputation rankings, with FogBugz Development Ninja David Fullerton also strong out of the gate.

In the past week or so, we've taken the additional step of moving all FogBugz 7 Knowledge Base Content onto the Knowledge Exchange.  (Users of the original FogBugz Knowledge Base will be redirected there automatically when they navigate to an article pertaining to FogBugz 7.)  It may seem a bit odd at first to have a dude named "FogBugz KB" lurking around, asking and answering his own questions.  But now that the KB content is on a StackExchange site, the community will be able to collaboratively edit and improve answers, provide alternative answers, and spin off related questions that will gradually fill the gaps in our collective FogBugz knowledge.

So if you have a question about FogBugz, be sure to head over to fogbugz.stackexchange.com and see if it's already been asked and answered (The StackExchange platform offers a fast full-text search of all content.).  If not, don't be afraid to ask.  No question is too newbie, and no question will remain unanswered for long.

No, it's not a cable news station, it's a brand new FogBugz Plugin that gives you up-to-the-minute updates on your team's activity.

The FogBugz News Network (FNN) Plugin allows you to quickly view the most recent updates to cases in your FogBugz database.  You can choose to see everything that's happening on your FogBugz site, or filter by project and/or user to zero in on the cases you care about.

The Plugin also includes a "Work In Progress" report that shows which cases users are currently working on, including updated estimates and time remaining values for each.

You can download the Plugin form the FogBugz Plugin Gallery.  To learn more about FogBugz Plugin development, check out our "Features" page, the FogBugz Developers Wiki and the Plugin Ideas Forum.

The FogBugz Team is pleased to report that the Balsamiq Mockups Plugin is officially out of beta and available for purchase.  We're huge fans of Balsamiq Mockups, and find it to be the ultimate tool for fast, effective spec writing.  The new FogBugz Plugin cranks the awesomeness up to 11 by allowing users to embed active, editable mockups in FogBugz cases and wiki pages. 

You can download the Plugin on Balsamiq's product page, or find it in the FogBugz Plugin Gallery.

To learn more about FogBugz Plugin development, check out our "Features" page, the FogBugz Developers Wiki and the Plugin Ideas Forum.

In a previous article, I wrote about the FogBugz Plugin Architecture, and how it lets us answer some very common customer requests without suffering from feature bloat. In this article we'll examine in detail one of our most popular plugins, Workflow, which does just that.

The Default FogBugz Workflow and Why It's Good

Out of the box, FogBugz provides an intentionally simple workflow for cases. Each case passes through three stages: active, resolved, and closed. When a case is created it is assigned to someone as an active case. When the issue has been dealt with, it is resolved. At that point, it automatically goes back to the original opener so that they can verify the solution. Once they are satisfied, they close the case.

This workflow turns out to work very well for a variety of case types. Bugs start out at a tester or user who found the issue, then go to a developer who fixes it and then resolves it back to the opener for verification. Features begin at the person requesting the feature, go to a team lead or developer to implement, and then end up back at the person who opened it to confirms that the feature meets their requirements.

Furthermore, this workflow encourages a particular way of using FogBugz. It encourages users to verify the resolution of cases, which means more bugs are actually fixed. It also encourages a simple process, so a developer can open a "remember to write the documentation" case without it having to go through six steps of approval. This means that more cases make it into FogBugz instead of ending up as sticky notes all over the monitor.

The default FogBugz workflow: active, resolved, and closed

When the Default Workflow Isn't Enough

Unfortunately, there are some cases where the default workflow breaks down. Sometimes a customer will open a case to report a bug, but they really shouldn't be responsible for verifying it. Often there is a QA person who should be involved in the process for certain categories of bugs. Or a team might want to differentiate between a feature that still being specced and one that is in development.

The default Workflow is very much a 90% solution: it works great 90% of the time (probably more, actually), but that last 10% of the time it just doesn't do what you want. The result is that you end up fighting with the tool, rather than having the tool get out of your way and allow you to get your work done.

At the same time, the last thing we want is for an organization to get FogBugz and then spend a week in meetings drawing flowcharts trying to decide what happens if a bug gets found by a tester in Department A, but it actually comes from a component developed by Department C, so it needs to be verified by the QA teams in both and there's absolutely, positively no way anybody can start creating bugs until this is figured out.

We want FogBugz to JUST WORK, right up until the point where it doesn't, at which point you find the super easy solution we've prepared for you, click a few buttons, and continue on your merry way.

Customizing the FogBugz Workflow

Fortunately, plugins give us a great way to have both simple, sane out-of-the-box behavior, and powerful customization only a few clicks away. For users who don't care or who find that the default workflow is good enough for them, FogBugz continues to work exactly the same. But for the users who need the ability to customize their system, the Workflow plugin can be installed with just a few clicks from the FogBugz Plugin Gallery.

The Workflow plugin allows users to customize workflow in two ways: by defining new categories and statuses, and by specifying how cases are assigned when transitioning a case between statuses.

The Workflow plugin adds a new item to the Admin menu

Custom Categories and Statuses

The first thing to do when customizing the FogBugz workflow is decide what types of cases the customization should apply to. This isn't always as straightforward as it seems. It may seem obvious that all bugs should have to be verified by QA, until you actually implement it and your developers start complaining that every time they create a little case for themselves to remember to fix something it has to be verified by QA. Before you know it, they're back tracking their bugs in notepad and you're amazed at how effective your new process is at reducing the number of bug reports in your software.

Since changing the workflow is potentially so disruptive, we recommend trying out major changes on an entirely new category, which the Workflow plugin makes completely painless to create. In our example, we might create the category "Bug (Needs QA)". Now developers can continue to create reminder cases for themselves that don't have to go through QA, and testers can create cases that will always follow your new workflow. Later on, with just a few clicks you can delete the old "Bug" category if you find you're not using it.

Once you have your categories nailed down, you'll want to create some statuses for them. Here you can take advantage of another new feature in FogBugz 7: multiple active statuses. Before FogBugz 7, all categories only had one active status: "Active". Now using the Workflow plugin it's possible to add multiple active statuses. For example, you could create the "Active (In Development)" status for bugs, or the "Active (Needs Spec)" status for features.

For our example above, we'll add two resolved statuses: "Resolved (Fixed)" and "Resolved (Verified)". When the development team has finished fixing the bug, they resolve the case as "Fixed". When QA has finished verifying the case, they'll resolve it as "Verified".

Add a new category with just a few clicks

Customizing Case Assignment

The other half of custom workflow is defining how cases get assigned when changing the status. In FogBugz 7, each project can have its own workflow. This allows you, for example, to have a special workflow just for the "Inbox" project, or have one workflow shared between all development projects.

Each workflow determines to whom cases are assigned for each status in four different circumstances:

1. Creating or Editing the status of an active case
2. Reactivating a resolved case
3. Reopening a closed case
4. Resolving a case

When selecting to whom the case is assigned, you can choose either a particular user (e.g. "Joel Spolsky"), or you can choose a special value such as "Primary Contact" or "Case Opener", or even "No Change" to keep it assigned to the same user.

You can also choose whether the assignment is forced. Forced assignment means that when the workflow rule is in effect, the "Assign To" dropdown will not be editable. This guarantees that the case will be at least initially assigned to the specified user.

For our QA example, we'll set the rules for our statuses as follows:

When Resolving a Bug (Needs QA),

• Resolved (Fixed) assigns to "Alison Tirrell", our QA lead, and is forced
• Resolved (Verified) assigns to "Case Opener", and is forced

For everything else we'll use the defaults. This will give us the following workflow for cases opened as "Bug (Needs QA)":

1. Case Opened
2. Active & gets assigned to a developer
3. Resolved (Fixed) & gets assigned to QA by the developer
4. Resolved (Verified) & gets assigned to the case opener by QA
5. Closed by the case opener

Using this workflow, we've preserved the original spirit of the FogBugz workflow, where the opener verifies a case, and added a QA step for bugs that need it.

Determine to whom cases are assigned by editing the workflow

What Custom Workflow Isn't

As powerful as this method of custom workflow is, there are a few things that it can't do. It doesn't allow restricting the order that statuses have to go in, so there's no way to say that the "Active (Needs Spec)" status must progress to "Active (In Development)" before going to "Resolved (Implemented)".

It also doesn't allow restricting on users: there's no way to say that only an administrator can close a case, or that cases with the status "Active (In Development)" have to be assigned to a developer.

Also, having a "forced" assignment in the workflow only determines who the case is initially assigned to. Once the case is assigned to a user by a "force" rule, it can be reassigned to anyone (though the original user will always get a notification that the case was assigned to them).

In this, workflow follows the FogBugz philosophy of keep it simple, and stay out of the user's way. If a non-QA user really wants to resolve a case as "Verified", they probably have a good reason to do so. If a user needs to grab a case back after it has been assigned to the Primary Contact for review, they probably know what they are doing better than FogBugz does.

Advanced Custom Workflow

With that said, it is possible to build on the Workflow plugin to create more advanced workflows. If you want to make sure that cases with status "Active (In Development)" are assigned to a developer, you could make a plugin that automatically finds cases in violation of this and reassigns them to an appropriate user.

You could also use plugins to create special virtual users that your workflow assigns to, which have a special meaning in the plugin. For example, you could create a "Case Owner" plugin that adds a new "Case Owner" field to cases, and then lets you choose "Case Owner" as the person assigned to when a case is resolved. Or you could make a "Round Robin" virtual user, and have the plugin distribute incoming cases to one of several users, and use this to handle incoming support requests.

A plugin could even do a similar thing with statuses, by having a special "Next Step" or "Auto" status. When a case is set to the status "Next Step", the plugin takes over and moves it to the correct status and assigns it to the appropriate user.

These are just a few ideas of advanced workflow plugins that could be created. If you have your own idea, you could add it to the Plugin Ideas Forum, or get started writing your own, and of course we'll be happy to answer any questions you might have in the developer discussion group.

We decided to add subcases
Customers have wanted hierarchy in FogBugz for years.  They wanted to break their cases up into subcases and add to-do lists.  They like things to nest.  Lots of other bug trackers try to satisfy these demands, and a long time ago we decided to make this a high priority for our next release.

How hard could it be?
It should've been a simple task.  Add subcases to FogBugz 7.  Users need the ability to break down their cases hierarchically or create simple to-do lists inside of their bugs.  Most people could code it up in a few hours, or maybe a caffeine-hazed weekend, right?

So why did we wait until FogBugz 7 to do this if people have been asking after it for years?  As it turns out doing it right took some time...as we've gotten used to when building a new feature.

Doing it right - The first stab
Like most things that go into FogBugz, we're highly concerned with getting it right.  Our features need to be intuitive, simple to use.  If we add too much complexity we risk becoming just another arcane project management system requiring an advanced degree in Ganttonomics to operate effectively.  

On the other hand if we made subcases too simple we knew that the whole implementation would be disappointing to users. 

One early design we considered was to nerf subcases by not making them full FogBugz cases.  Users would create little subtasks that were essentially one-level-deep lists within their bugs.  Wallah!  Task lists.  We get to pat ourselves on the back and tick off another "feature" on the giant feature matrix.  But we quickly realized we'd run into all kinds of complaints: "Why can't I tag my subtasks?", or "I need to assign these tasks to someone else, and I can't!"  Before you know it you'd be waiting for the next version to come out with all its grand promises: "FogBugz 8 -- now you can finally add a due date to your subtasks!"  We've seen such missteps made by others when new features aren’t fully integrated into the core of the product, and we knew this option would never be a winner.

Doing it right - Round 2
After we rejected the nerfed subcase option, our program manager produced a slick spec.

It was a great start, so naturally we immediately started to argue.  Everyone wanted to make a fantastic feature, and everyone had different ideas about how to do that.  So we went round and round...and round.  We finally settled on a design and implemented an initial version.  We showed it off as an internal demo.  Surprise!  We needed more and more changes until everyone inside the company was happy with what we had.  Then we ran usability tests with a couple FogBugz customers.  Lo and behold, we discovered some major problems with our display of subcases in the grid view.  Sometimes when sorting and grouping in the grid view a case belongs in more than one grouping.  For example, a case may be assigned to me and show up under the "Assigned to Ben Kamens" group, but it also belongs directly under its parent case, which is "Assigned to Joel Spolsky".  In those instances we were simply displaying the same case twice in the grid view under both groupings.  This basically caused people's brains to melt.

Doing it right - Round 3
We had to redesign again.  After that last usability test, I was 100% positive that showing a case twice in the grid view was a terrible mistake.  Luckily, Dan, our FogBugz PM, wasn't so sure; he came up with an excellent set of affordances to make the duplicate cases much clearer and to give users the option to just show all cases (including subcases) in a flat view.  He was sure we could do it right and he went to work on me.

We went round and around about this again, as the case below demonstrates (and trust me, this is just a portion of the back-and-forth).  There’s a lot of passion about these issues at Fog Creek.

I was eventually persuaded that we could show duplicates if we were very careful about how the display worked.  The next round of feedback showed that this was right, and the two views we built in were a big success.

Other challenges
Subcases also presented a purely technical challenge: We needed to query hierarchical case structures without slowing down FogBugz.  More accurately, we had to run fast hierarchical SQL queries (get me the children of case 5, and their children, and their children, ... ) in all three of our supported databases: MSSQL, MySQL, and Access.  The support for recursive queries in these three databases is varied at best, and nonexistent in one.  Can you guess which is which?

Turns out there's a pretty cool solution for this problem explained by Joe Celko.  Instead of attempting to maintain a bunch of parent/child relationships all over your database -- which would necessitate recursive SQL queries to find all the descendents of a node -- we mark each case with a "left" and "right" value calculated by traversing the tree depth-first and counting as we go.  A node's "left" value is set whenever it is first seen during traversal, and the "right" value is set when walking back up the tree away from the node.  A picture probably makes more sense:

How does this help?  Now we just ask for all the cases with a "left" value between 2 and 9 to find all of the descendents of B in one fast, indexed query.  Ancestors of G are found by asking for nodes with "left" less than 6 (G's own "left") and "right" greater than 6.  Works in all databases.  Greatly increases performance -- particularly when querying large hierarchies.

What we delivered
Waiting to add this feature was worth it. Initial customer reactions have been very positive, and we've even had people who had no real interest in subcases when they heard it was coming tell us that it's changed the way they use FogBugz. 

• We added a context menu to the grid view which allows you to very quickly add all your subcases right there.  This makes it super easy to set up a whole set of tasks and break them up into their parts without leaving the grid.
• The outline view lets users easily see their cases’ hierarchical relationships.
  
  
• We clearly mark subcases that exist but do not match your current filter or search.
• We've added auto-complete to the case view so you can make existing cases into subcases of the one being currently viewed by simply typing a case number or searching for words in its title.
• You have the option to resolve and/or close all subcases when resolving the parent case.
• Subcases are fully integrated with search, filters, and all standard FogBugz workflow.
  

That's the feature we fought so hard over.  So far the feedback has been uniformly good, and we think it's a keystone in our best release yet.  You should try it out and sign up for a free FogBugz 7 trial.
 

One of the major features Joel mentioned in the official launch of FogBugz 7 was "Scrum support."  Distilled to its essence, Scrum is characterized by:

1. Short "Sprints" that produce "Product Iterations": Each "Sprint" lasts around 15-30 days, and a release cycle can contain one or many product iterations.
2. The "Product Backlog": For each project, a "Product Backlog" list is kept that's essentially a feature wish list sorted by priority. The features are sometimes represented as brief "stories," such as "Allow FogBugz users to create subcases," and each is assigned a rough work estimate. The features that are higher up the list are given more detailed analysis in terms of work estimates and are broken down into greater detail.
3. Daily "Scrums": Once the sprint starts, the team holds daily 15-minute meetings, in which each member of the team summarizes:
   What tasks he/she worked on yesterday
   What tasks he/she will work on today
   Any Issues that might limit his/her progress
4. Burn Down Chart: Sprint progress is tracked through the use of the "Burn Down Chart," which plots the overall estimated time remaining (in the sprint task list) against the date. The goal is to keep things on track for a zero time remaining by the end of the 15-30 day sprint.

FogBugz 6 – already Scrum friendly?

Many of our customers told us that FogBugz felt too heavy for them to use in their Scrum shop, and we weren’t exactly sure why.  "FogBugz supports all of these things," we thought.  A Fix For in FogBugz can be used for every sprint.  Just order things by priority, and bam! Average-sized backlog.  Daily scrums have no place in a online tool, since that is antithetical to a short, daily meeting that is really not meant to be recorded. And the burn down chart was just a way of reading EBS graphs with your head tilted to the side a little.

Nah. FogBugz 6 didn’t work well for Scrum

Creating a Fix-For in FogBugz 6 took 5 clicks, and then you still had to change the Fix For on all the cases that were going into the sprint.  That’s pretty heavy.  Release notes were only useful if you used 1 Fix For per release.  That’s not the way Scrum works; usually there are multiple sprints per release, so whoever was responsible for release notes would have to splice together the FogBugz release notes by hand.

Also, FogBugz priorities are too coarse-grained to be useful for a product backlog; the backlog should be a full ordering, not just a set of buckets where we say "well, these cases are all pretty important, but these over here? Mega important." And if you use it that way, once you move cases into the sprint backlog from the release backlog, you have to reprioritize them, since they’re all going to be in the top 1 or 2 priorities anyway.  It just didn’t work.

Another big mistake was thinking that the Completion Date Over Time graph in EBS was essentially just a burn down chart. We were correct, in a way: the data source for the graph was the same data one would use to make a burn down chart. But the two graphs are used for different purposes:

For a sprint, which tends to be short, the work schedule-agnostic burn down chart actually makes a lot of sense, for three reasons:

• It illustrates an absolute finishing point. The date of completion is asserted, not predicted. If the burn down line is not on track for completion, functionality is removed from implemented features.

• Sprinting team members are likely to violate their work schedule. An "all-out" mentality is often applied to the latter stages of a sprint, and teams are often given an extended breather between sprints.

• Team members are more likely to pick up each other's slack. The team maintains a sharp focus on achieving sprint goals, even if one team member's schedule serves as a roadblock. They are likely to adapt in an unpredictable fashion and take on each other's tasks as necessary.

In contrast, the existing EBS-predicted ship dates are superior for planning a larger release further down the road:

• It predicts a finishing point. For a full release cycle, you want to identify feature goals first, and then let EBS produce a set of reasonable dates.

• Huge values of "hours remaining" are cumbersome.

• Work schedules will average out over a long release cycle, even if they vary during a sprint.

• Team members will maintain ownership over specific features over the long run, even if tasks shift around a bit during a sprint.

We fixed FogBugz 7 for Scrum shops

The first thing we did was to lighten up Fix Fors.  We renamed them to "milestones," which lets them be used more generically. The release notes page was tuned up to let more than one milestone be part of the list of release notes. Finally, the biggest improvement to milestones was on the grid view, where you can now create a new milestone and move all selected cases into it using 2 clicks. Changing the milestone on some cases is even easier, using the same button.

Secondly, the Project Backlog plugin was created to map product backlogs into the FogBugz world view.  For each project in FogBugz, the plugin keeps a fully-ordered list of cases in the project, and lets users move them around within that ordering.  When your team has an idea, they put a case containing the user story into the backlog.  If that user story gets into a sprint from the top of the backlog, then it’s time to start adding subcases to flesh out the different parts of the bug fix or feature.

Finally, we added evidence-based burn down charts.  Using the EBS 2.0 algorithms, we can calculate 5%, 50%, and 95% envelopes for how many hours are remaining in a milestone.  With this innovation, we use your developers’ estimation histories as a predictor for their estimation accuracy, and we can give you more accurate burn down charts than simply accepting those estimates at face value.  The deadline for the sprint is clearly marked with a vertical line.  If it looks like the Hours Remaining will chug down to zero before the deadline, you’re fine.  If not, it’s time to start cutting features like the BLINK tag that should’ve been cut so many years ago.

Daniel Root has posted a walkthrough on how he uses FogBugz 7 and Scrum.

"Every day of the Sprint, a very short meeting is held where the each team member says what they did yesterday, what they will do next, and if there's anything holding them up. If something is holding them up, it's up to the Scrum Master to make sure the problem gets resolved. At the end of the Sprint, the Team has a working product that is shown to the customer in a Sprint Review and/or deployed into production. Feedback is received and items added to the product backlog, and the process repeats until the project is complete. I'm sure true Scrum Masters will balk at some of this - we typically combine what would be a Sprint Review and Sprint Retrospective, and are fairly informal with the process. We don't call the meetings or people by their official scrum names- in fact most of our customers don't even know we're doing this to them!" 

Read More... 

Feature Bloat

Feature bloat is a familiar problem for any software project, especially one approaching a decade of continuous development.  For FogBugz, the sirens' call of bloat usually sounds something like this:

"Hi Fog Creek!  I love the new tagging feature in FogBugz 7!  My only problem is that I don't seem to be able to create a reverse-alphabetical, zebra-striped tag cloud.  In my organization we only use reverse-alphabetical, zebra-striped tag clouds and without them our entire production line has ground to a halt!  How soon will you be adding this feature?"

Now, 90% of our users have never even heard of reverse-alphabetical, zebra-striped tag clouds, and adding support for it to FogBugz will just add one more confusing feature and make FogBugz as bloated as the Michelin Man after Thanksgiving dinner.  But this is something that at least one customer really needs, and we don't want to just ignore them forever.

In the past we've always dealt with the threat of bloat by implementing the 90% solution really, really well.  The 90% solution means building the features that most people are asking for while we punt on the other 10%.  This lets us spend our energy on making sure the features for the 90% are both powerful and easy to use, and make our customers ridiculously happy.

Unfortunately, adding 90% solutions together doesn't mean that 90% of our users are 100% happy. That last 10% is never the same 10% for everyone, so we end up with an insane Venn diagram of competing desires, some of which may even be mutually exclusive!  With every release we address the biggest of these, but we also accumulate a few more customers who just wish we would add that one feature that would make FogBugz perfect for their organization.

One of our goals for FogBugz 7 was to provide a way of addressing all of these requests for features, without compromising the core simplicity and elegance of FogBugz out-of-the-box.

Sometimes we get carried away trying to make everyone happy

Enter Plugins

Plugins provide an elegant solution to this problem: create snap-on features that integrate seamlessly with FogBugz, but can be added and removed with the click of a button.  With a simple plugin, we can satisfy the 10% of customers dying for that reverse-alphabetical, zebra-striped tag cloud without the other 90% ever having to know that it even exists.

Even more exciting, plugins finally allow other people to modify FogBugz without having to dive into our scary Wasabi source code.  Anyone can write their own custom plugins, and then share them with the world in the FogBugz Plugin Gallery.

Installing plugins is dead simple: if you have FogBugz on your own server just download the zip file from the Plugin Gallery and click the upload link in FogBugz.  For FogBugz On Demand, just follow a link to the Plugin Gallery from your FogBugz account and it will be automatically installed when you click the install button.

Install plugins from the FogBugz Plugin Gallery with just a few clicks

The Plugin Architecture

So how did we actually do it?  First we had to port FogBugz from classic ASP to ASP.NET, but that's the subject of another post.  Once we did that, we were able to use some cool facilities built into .NET.

In FogBugz, plugins are simple .NET assemblies (DLLs) loaded into FogBugz.  As such, they can be written in any .NET language (C#, VB.NET, F#, etc.), and can leverage the powerful .NET Framework libraries.

These plugin assemblies communicate with FogBugz in two ways: by calling methods on the API, and by implementing special interfaces.

The interfaces that a plugin implements determine when and how FogBugz calls into the plugin.  Let's say a plugin wants to add a color-coded label to a case, and it should be displayed as a column in the case list.  All the plugin developer has to do is implement IPluginGridColumn, which specifies how to display the column and sort it, and FogBugz does the rest.  When FogBugz needs to display the column, it looks up the plugin and calls the appropriate methods (see an example).

Inside those methods the plugin will probably want to query FogBugz for some information.  It does this using special API methods that let a plugin do things like query the database, edit a case, or add a notification to the top of the page.  Since the plugin is running as an assembly on the server, there are no crazy hoops to jump through: for example, loading a bug is as simple as calling api.Bug.GetBug(caseId)!

Since these interfaces and API methods are the heart and soul of the plugin architecture, every single method and property has full Visual Studio IntelliSense documentation, and every interface has an example implementation in the Plugin Developers Wiki.

The FogBugz API includes complete Visual Studio Intellisense

What Plugins Can Do

So what exactly can Plugins do?  A lot, and we're actively expanding it.  Here are just a few quick examples:

• Create new FogBugz pages
• Add new column types to the case list grid
• Create custom fields on cases
• Extend search with custom search axes
• Add customizable filter criteria
• Load, modify, and save FogBugz entities like Cases, Users, Projects, Milestones, Wikis, and more
• Create custom database tables
• Query FogBugz database tables
• Create FogBugz "Editable Tables" with AJAX popups
• Write raw binary data and set content headers to allow custom file downloads
• Run periodic tasks during FogBugz background maintenance

Much more information and loads of examples can be found in the Plugin Developers Wiki; many of the examples above have a complete annotated example to help developers get started!

The Kanban Board plugin adds a new column to the grid

Plugin Security and AppDomains

Being able to run directly on the server is great for plugin developers, but it could be a nightmare for system administrators, especially for plugins coming from unknown third parties. In fact, our sys admins nearly had a fit when we first started talking about how plugins would work.  The problem, however, is not nearly as bad as it seems at first blush thanks to the power of .NET AppDomains.

AppDomains in .NET are a way to run assemblies in specially managed sandboxes with fine-grained control of what they can and can't do.  For example, the .NET FileIOPermission specifies what directories an assembly can read or write, and the WebPermission controls what URLs an assembly can hit over the web.  .NET itself defines dozens of permissions, and has facilities to allow developers to define their own.

So what permissions do we deny plugins in FogBugz?  Almost everything!  They are forbidden from accessing the file system or the registry, or connecting to databases, or running unmanaged code, or...well it's easier to say that we basically start with a completely blank slate, and only give plugins the handful of permissions they need to run.

"Wait!", you say.  "Plugins can't access the database?  How do they do anything interesting?".  Plugins aren't allowed to talk to the database, but FogBugz sure can.  So if a plugin wants to do something that it doesn't normally have permission to do, the request has to go through FogBugz via an API.  FogBugz, in turn, is very restrictive about what it allows plugins to do: for example, every SQL query is run through a validator to ensure that it doesn't do anything dangerous.

"But what if I want my plugin to be able to talk to another database", you cry again.  Well, in the 7.0 release all plugins run in a single, very restricted AppDomain, but in future releases we plan to add support for FogBugz administrators to loosen the restrictions for certain plugins known to be safe.  This would allow, for example, a plugin that integrates FogBugz with a sales database, or lets the plugin access certain network resources.

We start with a blank slate and only allow necessary permissions

Enforcing FogBugz User Permissions

Of course, when loading information from the database, Plugins need to be aware of another level of security: FogBugz user permissions.  Not every user in FogBugz has access to every case, or is allowed to modify a project.  To make things simpler for plugin developers and to reduce the risk of data exposure, whenever possible the FogBugz plugin architecture adopts a "fail closed" policy.

A "fail closed" policy means that by default we enforce the permissions of the current user when the plugin runs.  For example, if a user visits a plugin page that displays information about a case, a permission check is automatically run when the plugin tries to access the case data.  If the current user does not have access to view the case, the plugin will receive an exception.

Automatically enforcing permissions means that much of the time plugin developers can write without having to worry about permissions.  In the worst case, the plugin will return an error rather than revealing potentially sensitive data.  In the special situations where a plugin needs to do something unusual with permissions, it can turn off the automatic permission handling on an object and manage the permissions itself.

FogBugz automatically enforces the user's permissions

The Future of the Plugin Architecture

We're all extremely excited about the first version of the plugin architecture in FogBugz 7.  We think it provides a powerful foundation for a wide variety of plugins.  Already we've implemented several long-requested features for FogBugz as plugins: Workflow, Custom Fields, Project Backlog, and CSV Export (built-in to FogBugz 7) are just the start!

We're also excited about the plugins under development that will start to push the architecture to its limits.  The Balsamiq Mockups plugin allows creating beautifully simple user interface mockups from inside FogBugz which can be attached to cases and wiki pages.  The Kanban Board plugin allows creating an Agile Kanban board with FogBugz cases, complete with AJAX drag-and-drop.  You can browse these plugins and many more at the FogBugz Plugin Gallery.

FogBugz is just getting started with plugins.  Stay tuned in the coming weeks and months for more and more feature-loaded plugins, along with expansions and additions to the plugin architecture that will allow developers to do more and more.  If you have an idea for a plugin that you'd like to see, you can even suggest it to the development community at the FogBugz Plugin Ideas uservoice site, and maybe somebody will take it and run with it!

Or, even better, stop waiting for  somebody else to add reverse-alphabetical, zebra-striped tag clouds and get started writing it yourself!  The FogBugz Developer Wiki has all the information you need to get started, and the Plugin Developer Discussion Group is a great place to get all of your questions answered.

A simple "Hello, World" plugin is only a few lines long