Conclusion

In this tutorial, you saw how to build an Outlook 2007 solution
that makes it easy for the sales manager to respond to customer appointment
requests and schedule appointments in a timely manner.

The sample application has quite a bit of code to work with data.
This code is not at all unique to a solution where Outlook, or Word and Excel
for that matter, are the user interface. In fact, were you to create a Windows
Forms based application to retrieve and manager this customer information, you
would use the same data code.

The sample application also has quite a bit of code to handle
Outlook activities such as sending mail and creating tasks, as well as
scheduling meetings. That code is straightforward and requires only familiarity
with the properties and methods of various Outlook objects.

The hardest part of writing an Outlook solution lies in the
generic nature of the Explorer and Inspector windows. When you start Outlook,
you will typically see “the Inbox”. You can open “the Calendar”. In fact, there
is no Explorer called Inbox or Calendar. An Explorer happens to be displaying
items in the Calendar folder or the Inbox folder. However, both windows are
Explorers. Similarly, windows that display items, regardless of the folder they
are in, are Inspectors.

If you have your Inbox, Calendar and Contacts open, you have
three open Explorers. If you then have ten emails and five contacts open, you
have fifteen Inspectors open. You cannot refer to a specific Explorer or
Inspector in code. To refer to a specific Explorer or Inspector in code, you
have to look for it by name.

Today I'm happy to announce EBS 2.0, launching as part of FogBugz 7. EBS 2.0 introduces two new features that make it possible to model real-world projects: inter-project timelines and strict dependency modeling.

Inter-Project Timelines

In EBS 1.0, each project's timeline was considered individually, so it was difficult to model a dependency on a shared resource; for instance, if a system administrator had cases in multiple projects, FogBugz assumed that he would begin work on all of them full-time in parallel.



Instead, EBS 2.0 assumes that you will work on all of your milestones in order, but it allows you to take control of parallelization by assigning percent times to projects. So if you always spend 10% of your time recruiting, 20% of your time working on your Amazing FogBugz Plugin, 10% staring out the window, and the rest of your time working on your development tasks in all other projects, that's now easy to model.

 

This allows you to divide your FogBugz install into granular projects (per-client, for instance), and still get meaningful answers from EBS about when users will start and finish work. While EBS 1.0 could model the work of the traditional, project-monogamous software developer pretty well, EBS 2.0 allows, say, a visual designer or consultant - anyone who divides time between multiple projects - to express her schedule accurately.

Strict Dependency Modeling



EBS 1.0 didn't have strict dependencies. Each user was assumed to finish his tasks in the first milestone, then start working on the second immediately. And that's the way it was, and we liked it. Usually. FogBugz is optimized for tracking software projects, and in most kinds of software development, a strict dependency is the exception, not the rule. Even if I'm waiting for someone else to finish a component, I can look at its spec and write my software accordingly.



But! Sometimes you really can't start work on a milestone until something else happens first. For example, our sysadmins are stellar, but even they have a hell of a time racking hardware before it arrives, and we in turn have a hard time deploying and testing our software on servers with no operating system installed. In EBS 1.0, you just couldn't express this kind of strict dependency.



EBS 2.0 gives you the vocabulary of strict dependencies and start dates. You can now say "No one can travel back in time until the Flux Capacitor is complete and the duped terror cell steals the plutonium."

 

". . . AND we can't build the time machine until the DeLorean arrives on October 20th."



 

Though the interface is simple, these dependencies can be used to build up a much more realistic model of your work. Given your dependencies, EBS will now build a directed graph of all of your milestones. It combinines the simple EBS 1.0 timeline with any of the strict dependencies and start dates you specify in order to calculate probable ship dates and risk for all of your projects.