Heriot-Watt undergraduate prize winners receive their awards
March 12th, 2010Linq to Visual Tree
March 4th, 2010This blog post demonstrates a Linq API which can be used to query the WPF / Silverlight Visual Tree. You can find a few other Linq to Visual Tree techniques on other blogs, but what makes this one unique is that it retains, and allows queries that make use of the tree like structure rather than simply flattening it.
I have recently published an article on codeproject which describes a technique for generating Linq API for querying tree-like structures. This blog post makes use of a generated API for WPF / Silverlight. If you are interested in the more generic approach, and how this API was constructed, (and how it is influenced by XPath) head on over to codeproject …
What I will provide here is a brief overview of the Linq to Visual Tree API. The full sourcecode for this API is at the end of this article.
The Linq to Visual Tree API defines a number of extension methods on DependencyObject that provide mechanisms for navigating to other DependencyObject instances. I will provide a few examples that query the following simple markup:
<Grid x:Name="GridOne" Background="White"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <TextBox x:Name="TextBoxOne" Text="One" Grid.Row="0" /> <StackPanel x:Name="StackPanelOne" Grid.Row="1"> <TextBox x:Name="TextBoxTwo" Text="Two" /> <Grid x:Name="GridTwo"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <TextBox x:Name="TextBoxThree" Text="Three" Grid.Row="0" /> <StackPanel x:Name="StackPanelTwo" Grid.Row="1"> <TextBox x:Name="TextBoxFour" Text="Four"/> </StackPanel> </Grid> </StackPanel> </Grid>
We’ll start with a simple example. Include the Linq to Visual Tree namespace, then use the Descendants method to obtain all the descendants (i.e. children and children’s children, etc …) of an object within the
visual tree.
Descendants
using LinqToVisualTree; // all items within the visual tree IEnumerable<DependencyObject> allDescendants = this.Descendants(); /* gives ... 0 {Grid} [GridOne] 1 {TextBox} [TextBoxOne] 2 {StackPanel} [StackPanelOne] 3 {TextBox} [TextBoxTwo] 4 {Grid} [GridTwo] 5 {TextBox} [TextBoxThree] 6 {StackPanel} [StackPanelTwo] 7 {TextBox} [TextBoxFour] */ // all items within the visual tree of 'GridTwo' var descendantsOfGridTwo = GridTwo.Descendants(); /* gives ... 0 {TextBox} [TextBoxThree] 1 {StackPanel} [StackPanelTwo] 2 {TextBox} [TextBoxFour] */
Each of the extension methods also has a corresponding method with a generic type parameter that filters the collection to find elements of a specific type:
// all items within the visual tree of 'GridTwo' that are textboxes var textBoxDescendantsOfGridTwo = GridTwo.Descendants() .Where(i => i is TextBox); /* 0 {TextBox} [TextBoxThree] 1 {TextBox} [TextBoxFour] */ // a shorthand using the generic version of Descendants var textBoxDescendantsOfGridTwo2 = GridTwo.Descendants<TextBox>(); /* 0 {TextBox} [TextBoxThree] 1 {TextBox} [TextBoxFour] */
Elements
The elements extension method obtains all the direct children of an item in the visual tree:
// find all direct children of this user control var userControlChildren = this.Elements(); /* 0 {Grid} [GridOne] */ // find all direct children of the grid 'GridTwo' var gridChildren = GridTwo.Elements(); /* 0 {TextBox} [TextBoxThree] 1 {StackPanel} [StackPanelTwo] */ // find all direct children of the grid 'GridTwo' that are StackPanels var gridChildren2 = GridTwo.Elements<StackPanel>(); /* 0 {StackPanel} [StackPanelTwo] */
There are also, ElementsBeforeSelf and ElementsAfterSelf methods that return the elements before and after the item which the method is being invoked upon.
Ancestors
The ancestors methods traverse the tree towards the root, finding all the ancestors:
// the ancestors for 'TextBoxFour' var ancestors = TextBoxFour.Ancestors(); /* 0 {StackPanel} [StackPanelTwo] 1 {Grid} [GridTwo] 2 {StackPanel} [StackPanelOne] 3 {Grid} [GridOne] 4 {MainPage} [] */ // the ancestors for 'TextBoxFour' that are StackPanels var stackPanelAncestors = TextBoxFour.Ancestors<StackPanel>(); /* 0 {StackPanel} [StackPanelTwo] 1 {StackPanel} [StackPanelOne] */
Putting it all together
The Linq to Tree API not only defines extension methods on DependencyObject, but also the same extension methods on IEnumerable<DependencyObject>. Unless you have previous experience of Linq to XML, I would strongly suggest reading my codeproject article to understand how this works!
This allows you to form much more complex queries. For example, you can find all TextBoxs that have a Grid as a direct parent:
var itemsFluent = this.Descendants<TextBox>() .Where(i => i.Ancestors().FirstOrDefault() is Grid); var itemsQuery = from v in this.Descendants<TextBox>() where v.Ancestors().FirstOrDefault() is Grid select v; /* 0 {TextBox} [TextBoxOne] 1 {TextBox} [TextBoxThree] */
Here, you can also see we are mixing the fluent and query syntax for Linq. Both give the same result.
The next example finds all StackPanels that are within another StackPanels visual tree:
var items2Fluent = this.Descendants<StackPanel>() .Descendants<StackPanel>(); var items2Query = from i in (from v in this.Descendants<StackPanel>() select v).Descendants<StackPanel>() select i; /* 0 {StackPanel} [StackPanelTwo] */
Finally, this one-liner, outputs the entire visual tree in ASCII! It makes use of the DescendantsAndSelf, Ancestors and ElementsBeforeSelf methods, plus the funky Linq Aggregate method.
string tree = this.DescendantsAndSelf().Aggregate("", (bc, n) => bc + n.Ancestors().Aggregate("", (ac, m) => (m.ElementsAfterSelf().Any() ? "| " : " ") + ac, ac => ac + (n.ElementsAfterSelf().Any() ? "+-" : "\\-")) + n.GetType().Name + "\n");
\-MainPage
\-Grid
+-TextBox
| \-Grid
| +-Border
| | \-Grid
| | +-Border
| | \-Border
| | \-ScrollViewer
| | \-Border
| | \-Grid
| | +-ScrollContentPresenter
| | | \-TextBoxView
| | +-Rectangle
| | +-ScrollBar
| | \-ScrollBar
| +-Border
| +-Border
| \-Border
| \-Grid
| +-Path
| \-Path
\-StackPanel
+-TextBox
| \-Grid
| +-Border
| | \-Grid
| | +-Border
| | \-Border
| | \-ScrollViewer
| | \-Border
| | \-Grid
| | +-ScrollContentPresenter
| | | \-TextBoxView
| | +-Rectangle
| | +-ScrollBar
| | \-ScrollBar
| +-Border
| +-Border
| \-Border
| \-Grid
| +-Path
| \-Path
\-Grid
+-TextBox
| \-Grid
| +-Border
| | \-Grid
| | +-Border
| | \-Border
| | \-ScrollViewer
| | \-Border
| | \-Grid
| | +-ScrollContentPresenter
| | | \-TextBoxView
| | +-Rectangle
| | +-ScrollBar
| | \-ScrollBar
| +-Border
| +-Border
| \-Border
| \-Grid
| +-Path
| \-Path
\-StackPanel
\-TextBox
\-Grid
+-Border
| \-Grid
| +-Border
| \-Border
| \-ScrollViewer
| \-Border
| \-Grid
| +-ScrollContentPresenter
| | \-TextBoxView
| +-Rectangle
| +-ScrollBar
| \-ScrollBar
+-Border
+-Border
\-Border
\-Grid
+-Path
\-Path
Note: this was invoked after the LayoutUpdated event so that we not only see the elements from our XAML, but also the elements created from their templates, giving us our full run-time visual tree.
You can download a simple Silverlight application that demonstrated all the examples given above:
LinqToTree.zip.
Or, if you just want the Linq to VisualTree code, you can copy-n-paste from the windows below which has the entire API, which includes the methods illustrated above,, plus their IEnumerable equivalents, and a few others I have not illustrated.
using System;
using System.Linq;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Media;
namespace LinqToVisualTree
{
///
/// Adapts a DependencyObject to provide methods required for generate
/// a Linq To Tree API
///
public class VisualTreeAdapter : ILinqTree
{
private DependencyObject _item;
public VisualTreeAdapter(DependencyObject item)
{
_item = item;
}
public IEnumerable Children()
{
int childrenCount = VisualTreeHelper.GetChildrenCount(_item);
for (int i = 0; i < childrenCount; i++)
{
yield return VisualTreeHelper.GetChild(_item, i);
}
}
public DependencyObject Parent
{
get
{
return VisualTreeHelper.GetParent(_item);
}
}
}
}
namespace LinqToVisualTree
{
///
/// Defines an interface that must be implemented to generate the LinqToTree methods
///
///
{
IEnumerable Children();
T Parent { get; }
}
public static class TreeExtensions
{
///
/// Returns a collection of descendant elements.
///
public static IEnumerable Descendants(this DependencyObject item)
{
ILinqTree adapter = new VisualTreeAdapter(item);
foreach (var child in adapter.Children())
{
yield return child;
foreach (var grandChild in child.Descendants())
{
yield return grandChild;
}
}
}
///
/// Returns a collection containing this element and all descendant elements.
///
public static IEnumerable DescendantsAndSelf(this DependencyObject item)
{
yield return item;
foreach (var child in item.Descendants())
{
yield return child;
}
}
///
/// Returns a collection of ancestor elements.
///
public static IEnumerable Ancestors(this DependencyObject item)
{
ILinqTree adapter = new VisualTreeAdapter(item);
var parent = adapter.Parent;
while (parent != null)
{
yield return parent;
adapter = new VisualTreeAdapter(parent);
parent = adapter.Parent;
}
}
///
/// Returns a collection containing this element and all ancestor elements.
///
public static IEnumerable AncestorsAndSelf(this DependencyObject item)
{
yield return item;
foreach (var ancestor in item.Ancestors())
{
yield return ancestor;
}
}
///
/// Returns a collection of child elements.
///
public static IEnumerable Elements(this DependencyObject item)
{
ILinqTree adapter = new VisualTreeAdapter(item);
foreach (var child in adapter.Children())
{
yield return child;
}
}
///
/// Returns a collection of the sibling elements before this node, in document order.
///
public static IEnumerable ElementsBeforeSelf(this DependencyObject item)
{
if (item.Ancestors().FirstOrDefault() == null)
yield break;
foreach (var child in item.Ancestors().First().Elements())
{
if (child.Equals(item))
break;
yield return child;
}
}
///
/// Returns a collection of the after elements after this node, in document order.
///
public static IEnumerable ElementsAfterSelf(this DependencyObject item)
{
if (item.Ancestors().FirstOrDefault() == null)
yield break;
bool afterSelf = false;
foreach (var child in item.Ancestors().First().Elements())
{
if (afterSelf)
yield return child;
if (child.Equals(item))
afterSelf = true;
}
}
///
/// Returns a collection containing this element and all child elements.
///
public static IEnumerable ElementsAndSelf(this DependencyObject item)
{
yield return item;
foreach (var child in item.Elements())
{
yield return child;
}
}
///
/// Returns a collection of descendant elements which match the given type.
///
public static IEnumerable Descendants(this DependencyObject item)
{
return item.Descendants().Where(i => i is T).Cast();
}
///
/// Returns a collection of the sibling elements before this node, in document order
/// which match the given type.
///
public static IEnumerable ElementsBeforeSelf(this DependencyObject item)
{
return item.ElementsBeforeSelf().Where(i => i is T).Cast();
}
///
/// Returns a collection of the after elements after this node, in document order
/// which match the given type.
///
public static IEnumerable ElementsAfterSelf(this DependencyObject item)
{
return item.ElementsAfterSelf().Where(i => i is T).Cast();
}
///
/// Returns a collection containing this element and all descendant elements
/// which match the given type.
///
public static IEnumerable DescendantsAndSelf(this DependencyObject item)
{
return item.DescendantsAndSelf().Where(i => i is T).Cast();
}
///
/// Returns a collection of ancestor elements which match the given type.
///
public static IEnumerable Ancestors(this DependencyObject item)
{
return item.Ancestors().Where(i => i is T).Cast();
}
///
/// Returns a collection containing this element and all ancestor elements
/// which match the given type.
///
public static IEnumerable AncestorsAndSelf(this DependencyObject item)
{
return item.AncestorsAndSelf().Where(i => i is T).Cast();
}
///
/// Returns a collection of child elements which match the given type.
///
public static IEnumerable Elements(this DependencyObject item)
{
return item.Elements().Where(i => i is T).Cast();
}
///
/// Returns a collection containing this element and all child elements.
/// which match the given type.
///
public static IEnumerable ElementsAndSelf(this DependencyObject item)
{
return item.ElementsAndSelf().Where(i => i is T).Cast();
}
}
public static class EnumerableTreeExtensions
{
///
/// Applies the given function to each of the items in the supplied
/// IEnumerable.
///
private static IEnumerable DrillDown(this IEnumerable items,
Func> function)
{
foreach (var item in items)
{
foreach (var itemChild in function(item))
{
yield return itemChild;
}
}
}
///
/// Applies the given function to each of the items in the supplied
/// IEnumerable, which match the given type.
///
public static IEnumerable DrillDown(this IEnumerable items,
Func> function)
where T : DependencyObject
{
foreach (var item in items)
{
foreach (var itemChild in function(item))
{
if (itemChild is T)
{
yield return (T)itemChild;
}
}
}
}
///
/// Returns a collection of descendant elements.
///
public static IEnumerable Descendants(this IEnumerable items)
{
return items.DrillDown(i => i.Descendants());
}
///
/// Returns a collection containing this element and all descendant elements.
///
public static IEnumerable DescendantsAndSelf(this IEnumerable items)
{
return items.DrillDown(i => i.DescendantsAndSelf());
}
///
/// Returns a collection of ancestor elements.
///
public static IEnumerable Ancestors(this IEnumerable items)
{
return items.DrillDown(i => i.Ancestors());
}
///
/// Returns a collection containing this element and all ancestor elements.
///
public static IEnumerable AncestorsAndSelf(this IEnumerable items)
{
return items.DrillDown(i => i.AncestorsAndSelf());
}
///
/// Returns a collection of child elements.
///
public static IEnumerable Elements(this IEnumerable items)
{
return items.DrillDown(i => i.Elements());
}
///
/// Returns a collection containing this element and all child elements.
///
public static IEnumerable ElementsAndSelf(this IEnumerable items)
{
return items.DrillDown(i => i.ElementsAndSelf());
}
///
/// Returns a collection of descendant elements which match the given type.
///
public static IEnumerable Descendants(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.Descendants());
}
///
/// Returns a collection containing this element and all descendant elements.
/// which match the given type.
///
public static IEnumerable DescendantsAndSelf(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.DescendantsAndSelf());
}
///
/// Returns a collection of ancestor elements which match the given type.
///
public static IEnumerable Ancestors(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.Ancestors());
}
///
/// Returns a collection containing this element and all ancestor elements.
/// which match the given type.
///
public static IEnumerable AncestorsAndSelf(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.AncestorsAndSelf());
}
///
/// Returns a collection of child elements which match the given type.
///
public static IEnumerable Elements(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.Elements());
}
///
/// Returns a collection containing this element and all child elements.
/// which match the given type.
///
public static IEnumerable ElementsAndSelf(this IEnumerable items)
where T : DependencyObject
{
return items.DrillDown(i => i.ElementsAndSelf());
}
}
}
Regards, Colin E.
Using built-in, embedded and streamed fonts in Silverlight
March 1st, 2010Forcing Event Consumer Cleanup without Weak Events
February 19th, 2010This blog post describes a simple technique for ensuring that consumers of events unsubscribe their event handlers without the need for weak events.
I think the concept of managed memory, where the cleanup of unused objects from the heap is performed by a garbage collector, is a fantastic idea. It means that developers working with Java or C# (or other CLR languages) can often forget all about memory allocation, concentrating on more interesting tasks. However, whereas in the Java language the concept of memory leaks has almost completely vanished, they unfortunately rear their ugly head all to often when developing applications for the Microsoft Common Language Runtime (CLR). This is almost entirely down to one thing, events.
The problem with events is that they form a strong reference (i.e. a link between two object instances that prohibits garbage collection) in a manner that is not immediately obvious due to the syntax that event subscription uses. When subscribing to an event, the following syntax is used:
// subscribe to an event textBox.TextChanged += new EventHandler(TextBox_TextChanged); // or textBox.TextChanged += TextBox_TextChanged; // remove the subscription textBox.TextChanged -= new EventHandler(TextBox_TextChanged); // or textBox.TextChanged -= TextBox_TextChanged;
Note the second examples use the shortened syntax where the delegate instance, EventHandler, is not explicitly constructed but added by the compiler, there is no difference semantically.
By subscribing to an event the following relationships are constructed, with the direction of reference as indicated:
As you can see from the above, adding an handler to an event creates a strong reference from source to listener. This does not cause significant problems if the listener has a shorter or the same lifecycle that the source, as is the case where you add event handlers for controls in a Windows Form for example. However, if the source has a longer lifecycle than the listener, and the listener fails to remove its event subscription, a memory leak will occur.
In practice this kind of problem often occurs in modular applications where there exists some sort of Shell or Environment that raises events or acts as a mediator. Within this hosting environment their exists numerous loosely coupled modules which by necessity have a shorter lifecycle than their container. If a module subscribes to events from the Shell but fails to unsubscribe at the end of its life a memory leak occurs. In complex systems this happens surprisingly often!
A common solution to this problem is to use Weak Events. These are events where either the reference between source and listener is weak, meaning that listener can be garbage collected if it is only referenced via this event handler. An early implementation of this pattern was developed for WPF and is provided by Greg Schechter on his blog. There is also an excellent codeproject article by Daniel Grunwald which details many different approaches to creating weak event listeners and sources.
However, whilst liberally sprinkling weak events about your code will solve potential memory leaks, it should not be used as a replacement for proper event subscription clean-up. What if a module’s event handler performs non-trivial logic? Do you really want this to occur after the module is supposed to have been destroyed? So, how do you ensure that events are being unsubscribed? This can be done by code-review, or by making use of heap profiling tools such as dotTrace. With these tools you can run your application, create and destroy modules, garbage collect then inspect your heap to see that the modules and their related objects have been removed. If not, you can trace the object references to find the offending event handler. However, this is a time consuming process.
An alternative is to make use of the fact that events are simply delegates with a highly restrictive interface applied. However, within the class where the event is defined you can treat it as an delegate, allowing you to inspect its invocation list to find all the event handlers. Therefore, if you have a long-lived service component that raises events which are handled by shorter lived modules, you can check the event invocation list after all the modules have been destroyed at application shutdown to ensure that all modules have correctly unsubscribed. This can be achieved as follows:
/// <summary> /// An event which indicates that some stock price has changed /// </summary> public event EventHandler<StockPriceUpdateEventArgs> StockPriceUpdate; public void Dispose(object sender, EventArgs e) { // check that when this service is destroyed, that there are no event // subscriptions CheckEventHasNoSubscribers(StockPriceUpdate); } /// <summary> /// Detects whether an event has any subscribers /// </summary> [Conditional("DEBUG")] private void CheckEventHasNoSubscribers(Delegate eventDelegate) { if (eventDelegate != null) { // if the event has any subscribers, create an informative error message. if (eventDelegate.GetInvocationList().Length != 0) { int subscriberCount = eventDelegate.GetInvocationList().Length; // determine the consumers of this event StringBuilder subscribers = new StringBuilder(); foreach (Delegate del in eventDelegate.GetInvocationList()) { subscribers.Append((subscribers.Length != 0 ? ", " : "") + del.Target.ToString()); } // name and shame them! Debug.WriteLine(string.Format("Event: {0} still has {1} subscribers, with the following targets [{2}]", eventDelegate.Method.Name, subscriberCount, subscribers.ToString())); } } }
Here we have an event which our service raises, on disposal we check that the event has no subscribers. If any modules have failed to cleanup properly we see the following message:
Event: PriceService_StockPriceUpdate still has 2 subscribers, with the following targets: [MemoryLeakExamples.StockPriceViewer, Text: StockPriceViewer, MemoryLeakExamples.StockPriceViewer, Text: StockPriceViewer]
This message tells us how many classes still have referenced event handlers, and their type. This should make it very easy to pinpoint the memory leak.
The sourcecode for this blog post includes a very simple WinForms application where a Stock Price service raises events that are handled by simple UI modules that can be created and destroyed by the user. Run it in DEBUG mode to see the memory leaks! Look in StockPriceViewer to see how to fix the problem.
Download the sourcecode: MemoryLeakExample.zip
Regards, Colin E.
Picturing tweets turns into worldwide winner
February 18th, 2010Flex Sparkline
February 8th, 2010Communication is the Key
January 27th, 2010Presentation on Agile Development
January 27th, 2010Last week I gave a presentation on Agile Development for an event hosted by Codeworks and Sunderland Software City. This blog post is a brief review of my presentation and the event itself.
The event was titled, “An Introduction to Agile Methodology – Get a Head Start in 2010″, which was suitably broad for my liking! I have experienced heavyweight, formal methodology in the shape of the Rational Unified Process; At Scott Logic, we prefer the Agile way, keeping it light. However, we have a wide range of customers, each with their own preferred development process, so we must exercise further agility by adapting to their way of working. For this reason, I did not want to highlight a single Agile methodology, rather, the common themes held by all Agile methods. My talk was titled “With Agile Development – Communication is the Key”, which pretty much sums up my own opinion on what makes the Agile approach so successful.
To summarise my presentation in a single paragraph; requirements and estimation are probably two of the greatest challenges to any software project. Requirements are hard to capture and as a result most people would agree that it is better to allow them to evolve. Estimation is something that most software engineers would rather avoid! the most common approach is to turn to the most senior member of the team and go with what they suggest. Agile, iterative methodologies promote communication between team members, and between the team and the stakeholders. In this way, the stakeholders are engaged on a regular basis, hastening the evolution of requirements. As the team learns from their previous iterations, their estimations improve. Furthermore, estimation becomes a team exercise, with the team communicating / discussing the tasks. This provides a far superior estimate of effort and team buy-in. In short, the iterative cycles of any iterative methodology promote communication, and it is this which makes them successful. Or, even-shorter, my last slide pretty much captures what I am trying to say:
Following the talks, which included mine, an introduction to Agile Development from Andrew Rumfitt (Perfect Image), and a discussion of the application of Agile techniques to non software projects by Colin Ashurst (Durham Business School), everyone played the “Ball Point Game”. This is a simple training exercise where small teams are formed, the goal being to pass as many balls between the team members as possible in two minutes. However, the added twist is that before each 2 minutes “iteration” the team has to estimate how many balls they will pass. Interestingly, most teams got better with each iteration, passing more balls, but more importantly as they found their natural velocity, their estimates improved.
The Q&A session followed the game, with myself and Andrew fielding questions. This was certainly an interesting challenge! A few of my favourite questions were as follows:
“If you allow requirements to change, what about the project budget? I cannot see how this would be workable?”
Great question! and not an easy one to answer. The problem with projects where the price and requirements are determined up-front is that one of the two parties involved is probably going to be unhappy with the end result. If the requirements are set-in-stone, forming an immovable contract, their natural evolution is stifled. The customer may get exactly what the described at the start of the project, however, it is probably not what they want now after they have used the software and had a chance to think more deeply about the problem. With an Agile, iterative approach, the requirements change and improve as do the estimates. And, as a result, the original budget (or scope) may prove to be unworkable. However, this extra information empowers the customer, allowing them to make a decision about the financial impact of this change in their own requirements. Although, this will only work if their is good communication and trust. To quote the Agile Manifesto, “Customer collaboration over contract negotiation”.
“I am sure that you getter better at estimating after a few projects, however, if you start a project with an Agile approach, and a few days into an iteration you find that your estimates are totally wrong, do you stop the iteration and start out again?”
This question certainly reveals the fear that a lot of software engineers have of estimation! One important point to note is that the person asking the question indicates that they think you need to run a number of agile projects before you get good at estimating. I think this is a flawed assumption. Every software project is different, and there is a certain amount of learning involved in every project. You learn about the problem being solved and about the capabilities, or velocity, of your team. The “Ball Point Game” we played earlier illustrates this point quite nicely, every team, after a few iterations, started to give very accurate estimate. With short iterations the feedback is very rapid, as a result you do not need a lot of experience from previous projects to start giving accurate estimates.
Regarding the question itself, should you abort the sprint? I don’t think so. If everyone (developers, and stakeholders) has bought into the agile approach, what some might see as a failure should be seen as a valuable lesson. Continue with the sprint, maximise the learning. Do not abort the sprint and try to sweep it under the carpet! This does not promote openness. Besides, can you be sure that your revised estimate after just a few days is better? Have you learnt enough?
“Do you need the right tools and the right people for Agile development?”
Personally I would always value people over tools, regardless of the process or project. Agile development should be quite lightweight. You can probably get away with just a simple spreadsheet, or a few post-it notes!
One problem with an approach that favours communication is that software engineers are not always the most communicative. A recent codeproject survey confirmed the commonly held belief that most software engineers are introverts (the INTJ personality type was the most common). Whilst it is certainly not necessary that all team members are extroverts, I think it does help if individuals occupying certain key roles, where they facilitate communicati0n (such as the ScrumMaster in the SRUM methodology), are comfortable communicators.
A few questions followed about how you find the right kind of people. At Scott logic, our interviews concentrate far more on people’s problem solving abilities and how they tackle problems than on just writing code.
After these, and other challenging questions, we have a well earned beer and some food …
An interesting and enjoyable events.
Regards, Colin E.