So it's Estimation time again.  We've been using the Agile methodology for our project management for well over a year now, and while I think it's dramatically better than the waterfall model we had before, I can't help but think we've still to get it right in terms of estimation.

Our estimation technique involves the traditional agile approach of using Story Points, and comparing each Backlog Feature to eachother, and deciding on a relative size.  So, if I think that one story is worthy of size 10, but then I get a gut-feeling that another story will take twice as long to complete, then that story would be sized at 20.

Once you agree on how many Story Points you can achieve in a given cycle (Sprint, to use the terminology), you can select your immediate workload.

Fair enough, estimation is never going to be an exact science.  But I've got that feeling we can be a bit more accurate, or at the very least give reasons for our figures rather than just a shrug of the shoulders and a "sounds good to me" stare.

Function Point Analysis

I've given Function Point Analysis a whirl before.  And it's probably best filed under "Learning Experiences".  Not the best effort, but then I was fresh out of uni and the spec was incomplete, so that's understandable.  Also, I think we were trying to fly before we could crawl.... which is where maybe merging this approach with that of Agile's flexibility might, I repeat, might work.

Another slight criticism of Agile I have is that it's really really really hard to try and estimate how big a task is when all you've got to go on is a sentence from a product backlog.  No spec, no prototype, no nothing.  Okay, so you've got a bit of domain understanding and there's always people you can speak to beforehand to give you a picture as to what's involved, but until you've actually built a picture in your head in terms of Objects, I/O, UI etc.... it's all a bit 'up in the air'.  Admittedly, as is my current understanding, this is okay, and your estimations will get better as the project begins to take shape... but if we performed FPA on each feature then you would need to know, in advance, the following:

• Internal Logical Files
• External Files
• External Inputs
• External Outputs
• Queries

As well as the Value Adjustment Factor based on general system characteristics of the project, this would give some quantitative measurement of what is to be delivered.  And it has proof!  You can go back to someone's estimates and actually find out why Feature A came out as twice as complex as Feature B. 

Agile Function Points

So, this output then is just treated as Story Points are by Agile, in that x number of story points can be delivered in a week, and velocity can be used to guage future performance.

What the engineers are saying is, "look, we don't need a full functional spec and UI screenshots describing exactly how everything will work, but all we need to know is 1) What's coming in, 2) What's going out and 3) How much user interaction is there going to be?".  And the goal donors can say "Okay, so we've not told you exactly how we want it done, but we've given you enough information to go on that you can't come back to us in a month and say that the database schema has doubled in size".

And that seems like a decent compromise to me. 

I have to give a special mention to this tool as it helps me generate scripts for my Unit Tests really quickly.  It's free at the moment, although each version has an expiration date, but it's well worth a look if you need something to quickly generate scripts.

http://www.sqlscripter.com/

It's also an example of REALLY GOOD USER INTERFACE DESIGN.  The author has taken the time to predict what you're most likely to do and wrapped up any repetitive tasks (for example logging in to the same database with the same credentials, or scripting a certain subset of tables with the same criteria).  You can tell it's a bit rough round the edges, but then it's not a commercial product yet.

If you want to run some script before or after client validation has been performed, you'll need to redirect the WebForm_OnSubmit() function.  Because of the framework we are using, WebForm_OnSubmit() was returning false immediately, so adding anything to Page.ClientScript.RegisterOnSubmitStatement was never being run.

I didn't have time to sort out where in the framework this was being set up (never mind the impact analysis), so I re-directed the Submit of the form to call my function first, then called the WebForm_OnSubmit code as normal.

if (!Page.ClientScript.IsClientScriptBlockRegistered(submitRedirect))
            {
                StringBuilder sb = new StringBuilder();
                sb.Append("<script>");
                sb.AppendFormat("var oldSubmit = document.getElementById('Form1').onsubmit;");
                sb.Append("function mySubmit()");
                sb.Append("{");
                //Your code here
                sb.Append("return oldSubmit();");
                sb.Append("}");
                sb.Append("document.getElementById('Form1').onsubmit = mySubmit;");
                sb.Append("</script>");
                Page.ClientScript.RegisterClientScriptBlock(GetType(),
                    submitRedirect, sb.ToString());
            }

Thanks to http://forums.asp.net/p/1011848/1354154.aspx for this tip.

I was debugging on a colleague's Vista box the other day, and all of a sudden it kicked me out, resetting back into Visual Studio.

I remembered seeing a blog about this issue a while ago, and thankfully was able to find it again, so here it is in case you have encountered the same problem:

http://eamon.nerbonne.org/2007/11/visual-studio-2005-on-vista-timeouts.html

I'm sure you'll be aware of the different MVC frameworks currently out there on the web.  RubyOnRails, MonoRail, and the new Microsoft ASP.NET MVC framework all claim to accelerate web development by removing a lot of the mundane, monkey-work plumbing involved in creating a web project.

They also provide a clear separation of concerns, by separating the presentation, logic and data-access into discrete layers.  This has the advantage that we can then introduce unit-testing into our web project, and mock any required components.

So far so good, but personally having looked at these frameworks, I can't fit them into any projects I'm working on at the moment.  It seems to me to be a trade-off between how much control I need and how much it conforms to a typical web layout.  But that's maybe because I haven't actually tried them out on anything other than a sample project. 

Having said that I do like what they offer - GETTING THE CODE OUT OF THE PAGE. 

Essentially, I believe we can achieve this and also maintain a lot of the control by using the framework outlined below.

As you can see, we have our MVC-triad, with the Controller at the heart.  The Controller interacts with the View via an interface, with each concrete WebPage having a reference to the Controller.  The WebPage also CREATES the Controller object(s) it uses, passing itself (it's interface) in to the Controller's constructor.   When the User selects something on a Page, the Page then calls the required method on the Controller.  The Controller can then carry out any logic and indirectly navigate to another URL.  It does this via the View interface that it has passed to it in it's constructor.

This example shows how the Controller can be used to control application flow.  The user initiates a command on MainPage, which calls Controller.Do_Command1.  In this method, the Controller would then carry out any logic for that Command, but then wants to move to another page.  The Controller can't do this directly, so calls the Show_AnotherPage() method on IMainPage (the MainPage's view interface).  The concrete MainPage class then redirects to AnotherPage.

This example shows the Controller again controlling the application flow, this time with conditions.  You can see how this could be easily tested via mocking.

Admittedly, this framework still relies on the developer putting in a lot of the plumbing, which has been nicely encapsulated by other MVC frameworks.  However, with this you get complete control over what is happening, and you also get to use the traditional WebForms approach, complete with Viewstate et. al. which is essential for 'legacy' apps.  It also means you can pick and choose the areas in the project where you implement it. 

If I was starting a web app from scratch I'd certainly look into MVC ASP.NET and see how it would work, but if you want the benefits of code separation in your existing applications now, then this framework could be adapted very easily.

EDIT: I'm not sure I really would look into MS' MVC ASP.NET framework any more - I can't see what benefits I would get from it that I can't with this approach.