Archive for September 2007

Outlook using Word 2007 as HTML Rendering Engine

September 7, 2007


Interesting postings here, here and here.


August 30th Links: ASP.NET, ASP.NET AJAX, IIS7, Visual Studio, Silverlight, .NET

September 7, 2007


Here is the latest in my link-listing series.  Also check out my ASP.NET Tips, Tricks and Tutorials page for links to popular articles I’ve done myself in the past.

  • ASP.NET Charting with NPlot: Olav Lerflaten has a great article on that describes how to use the free NPlot chart engine for .NET to create professional scientific charts of data using ASP.NET.

  • Export GridView to Excel: Matt Berseth has another excellent post on how you can export data to Excel from within your ASP.NET application.

  • Using Coordinated Universal Time (UTC) to Store Date/Time Values: Scott Mitchell has a useful article that describes how to use the UTC format to store date/time values within a SQL database so that it is transportable across timezones.  This is important to think about if your business operates in multiple geographic locations (or if your hosted web-server is located in a different time zone).

  • Fixing Firefox Slowness with localhost on Vista (or XP with IPv6): One annoying issue I’ve run into with Firefox is that sometimes – when doing localhost development – it can take several seconds to connect back to a local page.  It turns out this slowness is caused by a Firefox IPv6 issue with DNS resolution.  Dan Wahlin has a good pointer on how to fix this.

  • ASP.NET AJAX Exception Logging: Kazi Manzur Rashid has a nice article that shows how to create an effective error logging system with ASP.NET AJAX to catch and record client JavaScript errors.

IIS 7.0
  • Developing IIS7 Modules and Handlers with the .NET Framework: Mike Volodarksy from the IIS7 team has an excellent step-by-step blog post that describes how you can now write HttpModules and HttpHandlers using managed code that participate in all requests to a web-server.  This enables you to easily do scenarios that previously required custom C++ ISAPIs to achieve.

  • LINQPad: Joseph Albahari has an incredibly awesome LINQ query expression tool that you can use to quickly try out LINQ expressions.  Think of it as SQL Query Analyzer – but with LINQ expressions as the queries.  Definitely a useful free tool to add to your toolbox.

Visual Studio
  • The SQL Data Tools in VS 2008: Rick Strahl talks about some of the new database schema comparison, data comparison and SQL Refactoring features within Visual Studio 2008.

  • Recreating ITunes in Silverlight: Jose Fajardo has an absolutely fantastic blog with a ton of Silverlight content on it.  One of the projects he has been working on has been recreating Apple’s ITunes Media Player using Silverlight.  Check out his multi-part blog series that discusses step-by-step how he built it.  Absolutely brilliant.

  • New Halo3 Video using Silverlight: The new Halo3 preview video was recently posted to the web – using Silverlight 1.0 to build a custom viewer and stream a HD version of it.  Click here for a lower resolution version if you are on a slow network.

  • Sudoku for Silverlight: David Anson has built a cool online sample using Silverlight that helps you play the popular Sudoku game.  Useful for both Sudoku addicts and developers wanting to learn Silverlight.  

  • Font Embedding and RSS data in Silverlight: Tim Heuer has a cool blog post that shows how you can create your own font-type and embed it within your Silverlight 1.0 application.  He then has his application retrieve dynamic content from an RSS feed and use the custom font to display it.  You can run the finished application online here (all of the text here is dynamic – not a screen-shot).

  • Silverlight Drag and Drop JavaScript Framework: Roberto Hernandez-Pou has a nice article and sample that describes how to implement a drag/drop mechanism for Silverlight 1.0 (using JavaScript).  This article is in both Spanish and English – scroll down if you are looking for the English version.

  • Pascal Support for Silverlight: RemObjects Software now has a project template for VS 2008 that enables you to write Silverlight 1.1 .NET applications using Pascal.  It is kinda wild to see a screenshot of FireFox on the Mac, running a Silverlight application, written with a Pascal code-behind file built with VS 2008. 

  • LLBLGen Pro V2.5 released: Last week Frans Bouma released the latest version of LLBLGen Pro, which is an excellent ORM implementation for .NET.  New features include richer auditing, authorization, and dependency injection support.

  • IronLisp: A new codeplex project has recently started that provides the beginnings of a LISP implementation for .NET which is built using the new DLR (dynamic language runtime) framework for .NET.  Earlier this month I was thinking to myself “I really need to spend some time using LISP or Scheme”.  Now I can do it on .NET.  Sweet.

Hope this helps,


August 30th Links: ASP.NET, ASP.NET AJAX, IIS7, Visual Studio, Silverlight, .NET

How Long Before Microsoft Releases a Mock Object Framework

September 7, 2007

Interesting and strong opinions. I’d like to find out the reasons behind each so that I can make an informed judgement when push comes to shove and everyone in our organisation is moved to TFS based technologies exclusively. 

It’s a bit early for predictions for 2008… but here’s mine, anyway…

NUnit wasn’t invented by the borg, so they made their own (crappy) developer testing framework…
NAnt wasn’t invented by the borg, so they made their own build script and runner…
Cruise Control wasn’t invented by the borg, so they made their own (crippled) build server…
Windsor wasn’t invented by the borg, so they made their own (lame) IoC container…
Aspect# wasn’t invented by the borg, so they made their own aspect framework…
NHibernate wasn’t invented by the borg, so they made their own (mostly crappy) ORM framework…

I guess RhinoMocks is next.

How Long Before Microsoft Releases a Mock Object Framework

Trying to answer hard questions about Agile development

September 7, 2007


My immediate organization (formerly Finetix) largely uses XP/Scrum practices, but much of our larger parent organization is still new to Agile development.  Since more and more clients are asking for Agile project delivery, several of my coworkers and I were asked to participate in an Agile roundtable event.  The roundtable was asked a series of five questions one at a time and then went around the table.  To the best of my recollection, here is a distillation of my responses.

Yes, my answers are very biased, but I’ve come by these bias honestly.  I’ve had mostly positive experiences with XP/Scrum, and nothing but irritation from working with waterfall mentalities.  It’s probably true that many shops don’t really do a strict waterfall in practice, but in a way that’s even worse to give lip service to the waterfall while working adaptively on the side.  Those shops are living a lie.  They’re trying to work adaptively since that’s the only real way to succeed at complex projects, but their project lifecycle simply doesn’t support that adaptation.  Any decent usage of an Agile process is built around gathering feedback and making adaptations.  We ought to just start telling ourselves and management the truth and bring this adaptation out into the open sunshine where it’s easier to control.

What about Fixed Bids?

I am largely passing on a question about doing Agile on a fixed bid, fixed deliverable project.  I don’t have any first hand experience, and my cheeky response is that it works the exact same way as any other process.  You do your damndest to estimate the work by breaking it down into as fine grained tasks as possible then work stupidly long hours when the estimate turns out to be wrong.  Yeah, the extra upfront work to do the estimate isn’t necessarily Agile, and probably makes the whole of the work more expensive than it would be otherwise, but the situation is what it is. 

I don’t really think the Agile answer to a fixed bid is any different from any other process.  I do think that Agile practices and project management can give you far more control and feedback on the “Iron Triangle” of resources, time, and features.  Agile/RUP/CMMI/waterfall whatever, the iron triangle constraints still apply.  If you try to lock all three constraints you’re in for either pain, unhappiness, or protective sandbagging in your estimates.  I would still choose to use Agile delivery for fixed bid projects because I think that is the most efficient way to execute and allows for the ability to fail “softly” with some fraction of the features instead of total abject failure to deliver any features on time like a waterfall project.

How do you create agile requirements? Some teams define stories poorly and then discover later that implementing these stories takes much longer than estimated. Does a note card’s worth of information provide adequate detail for a good estimate? Is it a problem if estimates are highly inaccurate?

I’m going to be brief here because I have a “Jeremy length” essay on Agile requirements coming soon that hits this topic in detail.  The short answer is that user stories on note card’s are definitely not enough information for good estimates.  That’s okay though, because that isn’t all the information.  Story cards are primarily a project management tracking device plus a way of creating a common language for the team.  The note cards are simply an icon representing some finite amount of work.  The actual estimates are produced by the team with the developers tasking out the larger feature with plenty of help from the anaylysts, customers, and project manager, but that conversation absolutely has to happen.  In an Agile project you are very consciously trading in intermediate deliverables for far more face to face communication.  If I’m allowed to have my way, the detailed requirements will be captured in the form of acceptance tests and largely automated – but only close to the time that a given feature is actually put into development.  There’s no use in doing detailed analysis for some feature that ends up getting scrapped.  That’s just waste.

Check out this link from Jim Shore:  Beyond Story Cards: Agile Requirements Collaboration

How is Agile different from RUP? Each has development and release in an iterative process. Unlike waterfall, both can have late inclusion of requirements.

I had fun with this one.  I should probably say that while I have plenty of “book” knowledge about RUP, I’ve never used it in anger.  I’ve spoken to many people that very happily transitioned from RUP to XP or Scrum and refused to ever go back.  I did try to champion a conversion to RUP at a former employer before running away to join the XP circus.  This is a partial repeat of an earlier post, but who cares?


Are they Iterative?
RUP is supposed to be iterative and the founders of RUP will turn their faces blue saying this.  The problem for me is that RUP still includes a lot of waterfall mentality baggage in the form of project phases.  The iterations are much longer and seem to really amount to mini-waterfall projects in their own right.  The typical RUP iteration lengths I’ve heard ranged from 6 weeks to a couple months
Extreme Programming uses 1 to 2 week iterations, Scrum teams originally worked in 30 day sprints, but the cross pollination with XP has led to shorter iterations.  Testing is engaged much earler in an Agile team. 

RUP is commonly disparaged for its dizzying array of intermediate deliverables.  Most are optional and teams are meant to pick and choose which deliverables are appropriate for their project.  Some of the RUP deliverables may simply be an excuse to justify the purchase of the Rational lifecycle products.
XP and Scrum used to be described as low ceremony, but that might be a bald faced lie.  The project management “ceremonies” are simpler, but have to be followed closely.  XP in particular will have more impact on the minute by minute activity and behavior of the team than any other process.

Rational is a software company that makes their living from selling their lifecycle tools.
There are tools from vendors that support or aid with Agile processes and practices, but by and large, Agile teams use far more open source tooling than non-Agile teams. 

I think that RUP is largely created by people with C++ experience.  Coding is nasty, brutish, and hard.  The only way to succeed is regimented discipline.  Quality gates and the creation of documents like the Software Architecture Document.
Most of the early Agile leadership had a background in Smalltalk.  Coding can be productive and pleasant, but the extreme flexibility of the language requires an internalized discipline.  There might not be many intermediate deliverables in XP/Scrum, but XP/Scrum requires a very disciplined approach from the developers in the form of Test or Behavior Driven Developement, Continuous Integration, and Simple Design (much harder than that sounds).


All UML all the time.  The Three Amigos were all architects and RUP has a strong emphasis on architecture.
The Simplest Thing that could Possibly Work, the Last Responsible Moment, You Aren’t Gonna Need It (basically, don’t ever do anything more complicated than what you need *right now*).  Most Agile proponents eschew UML, but I’d write this off more to personal preference than a real prohibition.  I do think that CRC cards and Responsibility Driven Design is more effective inside rapid iterations than even informal UML.

You’re an Agile team, but inside of a Waterfall environment.  Is it possible to remain Agile?  What compromises must you make?

You will absolutely have to compromise.  Your team may be flexible in regards to your feature ordering and iteration planning, but the waterfall team isn’t.  If a waterfall team needs something from the Agile team, that feature simply needs to be made a priority and played in the next iteration.  The other way around is more tricky.  Waterfall teams generally work off of longer plans and don’t have that type of flexibility.  If you’re going to be dependent upon work from a waterfall team you have to treat that dependency as a constraint. 

Here’s where I think the bitter irony is, the waterfall teams purport to be more predictable because they have a linear project plan, but those plans are rarely accurate unless the plans are constantly adjusted in the face of feedback.  Because those plans are never truly accurate, we need to be able to adapt if it turns out the waterfall team is late with their work.  I think that the flexible delivery schedule of rapid iterations should give us more ability to simply switch to working on other features

As an Agilist I try to make all design decisions at the Last Responsible Moment.  In the case of a dependency on a waterfall team, my Last Responsible Moment comes much, much earlier than it would if that same feature was completely controlled by the Agile team.  Much of software design is being cognizant of what design decisions have to be made and the appropriate time to make that decision.  In other words, you need to decide when to decide.  In this particular case, I have to make decisions earlier than normal just to determine the concrete needs from the waterfall team early enough to get those needs into the waterfall teams project plan.

There is a very serious mismatch in terminology and vocabulary between teams using XP or Scrum and other teams doing more traditional waterfall work.  They think we’re out of control and we think they’re largely nuts.  You will have to invest some time with the other management to make them understand, or agree on a compromise for, how the Agile team is going to communicate progress.  There are no real intermediate deliverables on a typical Agile project.  I take the fairly common viewpoint that the only real measure of progress is features completed that are potentially able to be shipped.

Project staffing can be the killer in my experience.  To really do an iterative lifecycle we really need to include the analysts and testers as part of the holistic team — and leave them there!  Part of the enduring allure of nice, linear waterfall lifecycles is the belief that analysts can be rolled off of a project early and testers only need to be on the project at the end.  It’s a nice little myth, but I’ve seen nothing but severe pain from that type of project staffing in practice. 

Trying to answer hard questions about Agile development

Extend Model View Presenter to ASP.Net 2.0

September 7, 2007


using ASP.Net 2.0 advanced features

Extend Model View Presenter to ASP.Net 2.0

BDD and "How Are You Going to Use That Information"

September 7, 2007


Fred George has a post called “And How Are You Going to Use That Information?” that strikes at the heart of the analysis practices in Behavior Driven Development.

I’ve been looking for a question like, “and how are you going to use that information”.  My team is probably going to get really fed up hearing this particular question as I often use variants of it when trying to drive home the importance of BDD to YAGNI-avoidance.  Fred’s way makes it much easier for me.

Here’s an example from a recent release planning meeting:

Other: I’d like to see the current SVN build stamp in the footer of the app’s web pages.
Me: Why?
Other: So I can include it in feedback on the pre-alpha previews.
Me: Can you give me a story for that?

My assumption here is that once the story is surfaced, the person I’m speaking with will see that the feature won’t be valuable.

Here’s a the same conversation (theoretically) from Fred’s universe:

Other: I’d like to see the current SVN build stamp in the footer of the app’s web pages.
Me: Why?
Other: So I can include it in feedback on the pre-alpha previews.
Me: And how are we going to use that information?
Other: To track which release the feedback applies to (presumably).

Since we’ve got an extremely small number of people in our preview pool (less than 10 presently), and since we’ve got very little functionality released for preview, the build number won’t really help with the actions that we take based on feedback.

With such a small dev team, and so few previewers, and so little functionality, it’s near impossible for anyone who is invested in the project to not know what feedback pertains to.

The build number stamp is superfluous to our ability to respond to feedback and take action based on the feedback.  Our review of the inbound feedback, and the prioritization of tasks happens as a matter of agile planning, which is an information-immersive negotiation for stakeholders and designers.

No one could possibly not know what the feedback pertains to and therefore having further qualification by build number doesn’t enable us to fulfill our responsibilities any better.  It does however arbitrarily cost us the time of implementing the build number stamp.

This information might be useful to us later – when we have more releases, more features, more feedback, etc.  If we were to put in the effort to build it now, we would – in Lean terms – be incurring inventory cost.

Asking “How are you going to use that information” forces us to look at the behaviors that capitalize on that information, or that are enabled by that information.  When we just declare that we need some piece of information or other without justifying it with a concrete user story, we’re just doing model-driven or data-driven design.

When I focus first on behaviors – especially user goals as expressed based on scenarios with realistic context – the understanding of the necessary data will simply become clear and evident.  If I get distracted in the details of data-driven and model-driven analysis, I run a really high risk of accumulating unneeded inventory and its associated costs.

Drill down on behaviors.  Find out if they are real and substantial, and then figure out the data needs.  Starting at data is often a crap shoot at best.  Behaviors will surface data needs, but the opposite is almost never true – not in any substantial and meaningful way that works against incurring inventory in any case.

BDD and “How Are You Going to Use That Information”

Look here for the hard answers

September 7, 2007


Last week I made a post called Trying to answer hard questions about Agile development.  The one question I had to largely duck because of a lack of experience was the dreaded “Fixed bid, fixed scope, whither Agile?” question.  It sparked a bit of conversation and some other posts that actually take on the question of Agile on fixed bid projects:

On a related note, check out Agile development in a FDA regulated setting.

Look here for the hard answers