The Fine Art of Requirements Gathering

I recently came across a Dilbert cartoon that really struck a chord with me so I'd like to share it here:




I've had the "pleasure" of being in this exact situation more times than I care to count. Through the years, I've met with consulting prospect after consulting prospect and been asked to provide a price and schedule for some concept so vague that the person looking to have it built has no idea what he's even looking for.

And this situation isn't unique to software. A former business partner of mine is a graphic designer. I have spent plenty of time working in his studio and have overheard him meet with countless clients that wanted a cool new logo, letterhead, business cards, website, whatever, but they had absolutely no idea what they wanted it to look like. They never hesitated to say they didn't like what he had done for them when he was left to make a guess without any real input from them.

In an ideal world, every customer (client, boss, or other consumer of your work) would know exactly what they wanted and would be able to articulate that desire clearly. Unfortunately, I don't think that world exists and if it does, I don't know anyone that lives there.

A Quick F# Update

First, a few people have asked me privately how "F#" is said. It is said as "F sharp", just as C# is pronounced "C sharp". I'm not sure why Microsoft decided that # should be spoken as "sharp" as opposed to one of the many other alternatives for this symbol, such as "hash", "pound", or "crosshatch".

Next, Chris Bowen has made the slides of his presentation that I attended and other resources which he spoke about available on his blog. The MSDN blogs have been intermittent for me over the past few days though, so you may need to reload a few times before his page displays for you.


And finally, I'll mention Foundations of F# again. I've only had time to
look at the first 3 chapters so far, which introduce the key concepts of F# to the reader, and briefly flip through the rest of it. So far I am very pleased with the book and I find Robert Pickering's writing style very easy to follow without going at a snail's pace. I definitely recommend this book for anyone either starting off with F# or even just looking to explore the possibilities.

An Introduction to Microsoft F#

Last night I went to An Introduction to Microsoft F#. It was hosted by the Cape Cod .NET User Group and the speaker was Chris Bowen, a Microsoft Developer Evangelist. Chris was one of the two presenters at the Microsoft Northeast Roadshow in Waltham last month and he will be participating at the Boston MSDN Developer Conference next week.

Chris and Jim O'Neil cover New England as well as upstate NY for Microsoft and they both seem to really know their stuff. Last night was the second time I've seen Chris present and I have also seen Jim twice. They both speak intelligently and with an impressive breadth and depth. They are knowledgeable about a wide range of topics and can give an overview comparison or drill down into the nitty-gritty and go through detailed code with you as the situation requires. Both Chris' blog and Jim's blog are worth watching for upcoming events and generally useful info related to Microsoft technologies. They also both typically post slides and examples from past events they have run, so you can benefit from presentations that you were not able to attend.

F# is a newer .NET language that has come out of Microsoft Research. It is currently available as a CTP and will ship as part of Visual Studio 2010. It is a functional language (as opposed to being imperative such as C# or VB.NET or Xbasic), type-inferred, and interactive. Yes, this means that Visual Studio gets an interactive window for F# where you can play with the full .NET framework. Just as you might use Alpha's interactive window to create an Xdialog and manipulate it for testing/debugging, you can use F# to create a WinForm (or any other .NET object) and manipulate it interactively.

There are 4 main areas that I found most intriguing about F#: concise syntax; curried functions; parallel programming and language orientation.

Concise Syntax
It takes little code in F# to do a lot of work. That alone isn't overly alluring, but this may have benefits in code generation. I won't say much about this because code generation is a pretty narrow topic, but one that I am interested and one that has a role within my current job.

Curried Functions
F# creates curried functions, which means that a function that takes multiple arguments is generated as a series of functions, each taking a single argument, that when chained together creates the desired output. What this provides is an easy way to extend and reuse code. This might be best explained with a simple example. You might define a function to multiply two numbers:

let multiply a b = a * b

If you then call multiply 2 3, the expected result of 6 will be returned. But if you find yourself multiplying an awful lot of numbers by three, you might find a new function to be useful

let triple = multiply 3

So now there is a new function, triple, which exploits multiply. At first glance, this isn't too extraordinary since functions can call functions in other languages. But if you look closer at the definition of triple, you'll see that it doesn't deal with any input arguments at all, which becomes more useful and powerful in a more complex function.

Parallel Programming
One of the implications of being a functional language is that everything in F# is immutable by default (essentially a constant). What falls out of this immutability is near-trivial parallel code.

One of the slides that Chris went over was a small image manipulation routine that modified 1000 (I believe) images in parallel. He first showed the C# implementation, which at 3 pages of code was considerably simpler than I would expect from a C implementation. Then he showed us the equivalent F# code, which was about 10 lines.

There is no need to think about things like threads, mutexes or race conditions with F# because nothing can step on anything else (unless you specifically code it to be mutable). Working asynchronously in many cases is just a one character change. And because F# runs using the .NET runtime, you get the same performance as doing it "the hard way". Chris' C# and F# did the same work in the same amount of time.

One character? Really? Yup. Given serial code:

let longRunningCalculation = ...

It can often be safely made to run asynchronously by adding a single character:

let! longRunningCalculation = ...

Language Orientation
Language Oriented Programming is a vague term that is a bit difficult to clearly explain, and Chris did not say much on the subject so I need to do some more investigation. But basically, LOP allows F# to be extended to support a different language syntax. Again, a topic with narrow interest, but one which has its place on projects I am currently working on.

Resources
fsharp.net - the main Microsoft site for F#. This is where you can download the F# CTP to start working with F# in VS 2008.

Chris highly recommended two books:

1. Foundations of F#
   
2. Expert F#

Additionally, he recommended creating a new VS project using the F# Tutorial Project type after installing the CTP and working through it. He said it gave pretty good coverage of F# concepts and was a good way to get up to speed with the language.

Don Syme's blog - Don is the creator of F# and the author of Expert F#, mentioned above

MSDN F# samples - Chris gave us a quick overview of Samples101, SolarSystem and 3DVisualization. Samples101 is itself an interactive WinForms F# application (a la Learning Xdialog) which demonstrates 101 samples. SolarSystem is a nice example of parallel programming which creates a small window animating the orbit of planets in our solar system. 3DVisualization does some pretty cool graphing using DirectX.