Demystifying a Black Art

I'm working my way through Steve McConnell's Software Estimation: Demystifying the Black Art.

He starts off by making it clear that estimates are NOT the same thing as targets or commitments. Often business partners might ask you for an "estimate" when really what they want is a commitment to a target date.

In fact, estimates should be seen as probability statements. Steve recommends you always give estimates as a range like "2 to 5 weeks", or as a number plus a probability like "I'm about 80% confident I can get this done in 4 weeks." I personally think giving a range is a much better practice - business partners are too quick to forget the stated probability in the latter approach.

So what is a good estimate, for most people not building bridges or nuclear reactors? Here's how he defines a "good estimate:"

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.

The idea? Get the target date and estimate date range close enough and a good project manager can get the project in on time be shifting resources, simplifying/dropping requirements, etc. The estimate serves as a way to see if you are close enough to make the target date a reality with tweaks along the way.

Anyway, if you are interested in learning more, consider buying the book.

System.ServiceModel.Syndication

Eventually, I'd like to add a "tfsweb" capability to Team Foundation for Mono, that would, as much as possible, mimic gitweb's capabilities.

With this in mind, I'll need to create Atom/RSS feeds to which users can subscribe so they can track changes to a TFS repository over time.

In hopes of not having to rewrite the Atom/RSS code sometime in the future to leverage the .Net 3.5 syndication classes, I'm taking a crack at adding the System.ServiceModel.Syndication clases to the mono olive tree.

As a starting point, I'm trying to make Matt W's syndication example code produce the same output on MS.Net and Mono. Is anyone else working on this namespace? Right now I have:

Assembly/AssemblyInfo.cs            |   57 ++++++++++++++++++++++++++++++++
Atom10Serializer.cs                 |   54 ++++++++++++++++++++++++++++++
Makefile                            |   22 ++++++++++++
README                              |    4 ++
SyndicationContent.cs               |   45 +++++++++++++++++++++++++
SyndicationFeed.cs                  |   63 +++++++++++++++++++++++++++++++++++
SyndicationItem.cs                  |   57 ++++++++++++++++++++++++++++++++
SyndicationSerializer.cs            |   50 ++++++++++++++++++++++++++++
System.ServiceModel.Web.dll.sources |   11 ++++++
TextSyndicationContent.cs           |   64 ++++++++++++++++++++++++++++++++++++
TextSyndicationContentKind.cs       |   40 ++++++++++++++++++++++
11 files changed, 467 insertions(+)

Not a whole lot yet, but on the other hand this looks like a pretty straightforward namespace to implement that won't take alot of time.

tf4mono version 0.4.4

I've pretty much implemented all the features I'm looking for in a Team Foundation client for Mono, added all the usability enhancements necessary for things like password caching in the gnome keyring, and added some configuration extras for those who don't like the default behavior of the TF SCM client. Its all packaged up into the 0.4.4 release of tf4mono.

I tried taking a crack at implementing a TF version control plugin for MonoDevelop, but the way TF works is so much different than SVN, that I'm having second thoughts about this approach. I'm thinking now that maybe I should base something off of the Mono.Addins infrastructure. TF has all this stuff about workspaces, mapped paths, read-only files till checked out, etc. that don't mesh well with the traditional SVN/CVS model. Its more akin to Visual Source Safe.