Living in the Tech Avalanche Generation

I decided to share my experiences on the path to IronRuby so far and perhaps it might be useful to others who wish to travel that road.

Not so long ago I posted about choices in front of me regarding learning a new language. After having programmed in C# for some 7 or so years I wasn’t going to choose another statically typed language, I wanted to add a dynamic language to my arsenal and with the DLR on it’s way and a key interest and stake in the Silverlight, the choice as obvious.

After having decided to dedicate the time and effort to IronRuby, the next question was how to address the learning. Clearly picking up IronRuby as the first pit stop was going to come with some difficulties borne out of the fact that the documentation isn’t great yet and the toolset way of being close. Based on this, I decided that learning Ruby first was the best way to progress this goal for two main reasons, one it allowed me to learn in the comfort of an IDE (NetBeans) to write ‘do as you learn‘ code and also gave me a perspective on IronRuby that is not indifferent to its genealogy.

So after downloading NetBeans (Ruby Edition) and installing Ruby 1.8.6, I got my hands on the excellent free online book by Jeremy McAnally, the title of which is “Mr Neighbourly’s Humble Little Ruby Book“. This book is a nice little quick starter to get you comfortable with the absolute basics of Ruby, but needs to be followed by something with a bit more industrial strength such as Matz very own offering The Ruby Programming Language.

Once having navigated this far, I decided that it was time to pull down the IronRuby bits and start to have a play. A while back now, Hanselman and Gu both posted some early pieces on getting started with IronRuby. Most people seem intent on making XAML based applications the focus of their IronRuby attention, which in turn lead me to DLR Pad (see the image above) which provides the ability to interactively script IronRuby (and IronPython) against a statically set window that contains a XAML UI layout (interesting). From there I found my way to Ivan Porto Carerro’s blog and book on IronRuby. Ivan’s book is not yet released but is available as early access, so I decided to avail myself of it.

And if your wondering what code looks like (see below) for something that you might have been routinely doing (as I was), it doesn’t take long to knock something (trivial in this case) together to begin to get the picture, in the case of having gone down the path I described above.

require ‘mscorlib’
require ‘System.Windows.Forms,
  Version=2.0.0.0, Culture=neutral,
  PublicKeyToken=b77a5c561934e089′

begin

    #alias the forms namespace
    Windows = System::Windows::Forms
    #new up a form & set it’s text
    first_ruby_window = Windows::Form.new
    first_ruby_window.Text = “Simons first Ruby Form”
    #new up a button
    first_ruby_button = Windows::Button.new
    #subscribe to the buttons click event
    first_ruby_button.click {|sender, args| first_ruby_button.Text =
                                    “I got clicked!”}
    #add the button to the form
    first_ruby_window.Controls.Add(first_ruby_button)
    #show my new form
    first_ruby_window.ShowDialog()

end

And we get the following:

So that’s my story (to date) and perhaps it offers some help in getting you underway with your IronRuby / DLR journey.

BizTalk Express - Oh well got the name wrong - they called it Dublin. I want to make this the last post where I use the term BizTalk Express.

PDC is on our doorstep and the last minute information leak is starting to turn to a  steady stream, the one that most interested me recently came from Darren Jefford just a few days ago. Darren speaks about how Dublin (the new WCF / WF Application Server Host) will help in making both those technologies scale to enterprise without developers having to write a whole lot of infrastructure code. Darren say’s….

“So if you want to expose [WF] workflow’s via [WCF] services but ensure performance and scalability (up to enterprise scale), you can now do this without having to write the code required to host these apps on Windows Server.  Ensuring performance and scale of WCF services and WF is hard to do today, hence it’s not done very often at least in my experience and sometimes causes a tendency to twist BizTalk into doing something it wasn’t necessarily designed to do which causes problems of their own (coupling Web Sites/UI’s directly to BizTalk for synchronous processing springs to mind).

We don’t want customers in this situation to be forced into writing huge amounts of hard plumbing code to achieve this, we need a server product to do this for you, which is where Dublin comes in.  Note some of the server features announced which will be familiar to BizTalk developers (content based routing, compensation, etc.).”

So it would appear that some of the benefits of BizTalk are being borrowed and leveraged to provide application developers the ‘Server’ or ‘Host’ product and even some content based routing (both requests in the call for BizTalk Express). However part of my previous assertions was that by providing BizTalk Express (conceptually), we might become the beneficiaries of a robust and scalable host for our messaging and long running workflow technologies, there is still one point that I maintain is of significant importance that should not be overlooked and that is the requirement for Publish / Subscribe. So I am still left with this question dangling:

“How deep will all this declarative tooling go? How far does Dublin reach down into the API? Do I get publish / subscribe with my WCF / WF messages / workflow’s? What about durable messaging regardless of transport and bindings - I don’t care to lose messages on the HTTP stack?”

Whilst the information seems to be coming a little thicker and faster, some of these questions remain unanswered. I am also very interested in how flexible these new shiny toys will be? I for one don’t particularly like the RPC / CRUD styled interfaces that you see being developed ad nauseam in the Web Service space, that approach does not feel at all like messaging to me - it’s more like remote RPC API calls than it is messaging. Does Dublin and the Oslo suite of tools offer me the environment to take advantage of sending business messages or will it continue to encourage RPC styled API calls with better hosting and scale features out of the box?

I’m sure there is a lot more to the Oslo story that will be unveiled in the next month and I remain hopeful that some of my wish list is on the menu.

One of the areas that Agile methodologies suffer in, is a perception war that is built on the premise that ‘estimation’ comes with the risk of project approval and kick off via techniques such as velocity. Some believe that to be truly agile there is no up front estimation, only estimation as expressed through the ‘iterations’ and using ‘velocity’ to measure.

One question I keep hearing over and over again is:

"what do we tell our clients when they insist on having some kind of up front estimation on how long the project will take to complete?"

Some clients will NOT move forward with any commitment at all until they have some form of an estimate, so what do I do now? Don’t get me wrong, I am not advocating fixed priced contracts here (oh dear me no - that will be a subject for a later post), what I am offering here is the idea that initial requirements gathering (the functional & non functional) can be captured by using Agile ‘User Stories’ and plugged into the point case estimation formula and subsequently used to provide the client an estimate that they wouldn’t otherwise agree to progress the project without. Let me give you a real world successful example of a two week effort in project scoping and estimating.

The User Stories

In week one, our Architects sat with the client subject matter experts and internal development team and discussed the nature of the system required. The conversations revolved around both the functional and non-functional aspects of the system and included our architects modelling the domain.

In week two our Architects set about documenting the notes and drawings from week one and converting that information into our organisations internal representation of a user story. The organisation I work for practices it’s own hybrid ‘Agile’ methodology, incorporating practices from XP such as User Stories, Pair Programming, Continuous Integration, regular release to the stakeholders and other attributes successfully employed in the past by various members of our team.

Granularity of a story

The User Story itself is fairly coarse grained compared to some anecdotal comparison to what I hear from people in the industry and from my reading in the blogsphere; it does include the textual description of the story however also includes a Use Case Diagram to express the story in graphical form. We find the Use Case diagram useful to communicate parts of the system both to developers and the business .Each story is also accompanied by what we refer to as the Detail Table, which is primarily composed of aspects on each story that complete as much detail about pre and post conditions, architectural context, inputs and outputs, success and fail scenarios and more. Figure 1.0 below is a freehand drawing of a typical User Story without the detail table.

Figures 1.0 & 2.0 - The User Story and Detail Table

The Point Case Estimation Tools

Point Case Estimation formula appeared in the early nineties and provides estimations for predicting the duration of producing software components and applications. For a detailed explanation on the method please read further using these resources.

http://tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/

http://tynerblain.com/blog/2007/02/19/software-cost-estimation-ucp-6/

Also you can download a spreadsheet that performs the calculations to provide your estimate from here.

My personal experience with this method has been very satisfying, it allowed us to set our engagement with an initial estimation and the project estimates have more often than not turned out to be almost spot on with the actual deliveries. Bear in mind that the estimate should be treated as exactly that - an estimate (my group charges time and materials) and is not recommended as a instrument to provide fixed price bidding!