BDD Breakfast in Zürich

Next Tuesday (16.3.2010) my employer TechTalk is arranging a breakfast in the Technopark in Zürich.

Christian and I will hold a technical talk about Behavior Driven Development (BDD) and also present examples with SpecFlow.

The event starts at 8:00. Everybody is invited. Its free and there will be coffee and croissants. Please register here.

follow me on twitter, I need some friends :-)

Dead-End Heroes

Apart from the wonderful scottish accent there was one train of thought that particularly caught my interest in SE-Radio Episode 156: Kanban with David Anderson:

Estimation is a choice! Estimates lead to commitments that drive a dysfunction that is undesirable:

Estimates lead to setting an artificial target and forcing people to meet that. That tends to drive heroic behavior. [...] When people act heroically they stop improving [...] and they stop learning.

- David Anderson, SE Radio #156

follow me on twitter, I need some friends :-)

Phrases that should set off an alarm in every software developers brain

In software development there are some requirements that should immediately trigger all available bells in your subconscious alarming system:

This must be in real-time

The system must support historisation

The system must support multitenancy

The system must provide reports for every screen.

Usually those sentences are just mentioned as side notes or in the small print, as if they go without saying anyway and are the most evident thing in the universe.

But usually they imply a huge communication gap, that can cost buckets of money and bring wagon loads of grief.

Do you know other requirements that fall into the same category?

Update: @asztupak on twitter

It should support all features the previous system had

Update: Comments on Hacker News

follow me on twitter, I need some friends :-)

Inspiring talks

Sometimes we have to look beyond our noses. This is especially true when we are getting bogged in the trenches of corporate IT, getting lost in the big ball of mud, filling our brains with WTF from reading wagon-loads of legacy code...
Here are two inspiring talks by two brilliant minds:


"Unlearn your MBA" by David Heineimeier Hansson:




And the already classic "The Art of the Start" by Guy Kawasaki:

follow me on twitter, I need some friends :-)

Software: Sadly we did adopt from the construction analogy

In the software industry we often use analogies from civil engineering. We use terms like "architecture" and "construction".

But there is a common claim that we should learn more from classical engineering disciplines like civil engineering. According to that claim the IT industry would be a better place if we would adopt best practices from the latter.

On the other hand there are sophisticated explanations why software projects cannot be compared to construction projects.

Now that's all nonsense! The following quotes show that we actually do adopt eagerly:

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

- Alan Kay

Software and cathedrals are much the same – first we build them, then we pray.

- Sam Redwine

follow me on twitter, I need some friends :-)

The Agile Testing Quadrants

Discovering the Agile Testing Quadrants was close to an epiphany to me.
They helped me to think much clearer about the different concepts, disciplines and fields of software testing.

The original concept is from Brian Marrik, but the quadrants are discussed in depth in the brilliant book "Agile Testing" by Lisa Crispin and Janet Gregory.

There is also a presentation from Agile Vancouver 2008 held by Janet Gregory.

A project can draw different benefits from each of the testing quadrants:

Traditional software testing focuses almost exclusively on the right side, critiquing the product but not playing a productive part in supporting the creation of the product.
Traditional software testing is involved late in the development process to detect bugs but not to prevent them.

The lower left quadrant is the typical developer testing. Unit-testing and integration-testing, hopefully automated and with continuous integration, are quite common practice today.

The upper left quadrant is where we are entering quite new territory compared to what is common practice in the industry.

It's here where we place Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD). Those are quite new agile methodologies that focus on improving quality by placing activities from testing early in the development process. Those activities are constantly supporting the development process throughout its whole duration.

However it's important to understand that all testing quadrants are important. It's not that focusing completely on one quadrant can make the other quadrants completely obsolete. However a well tailored testing strategy uses all quadrants appropriately to improve testing as a whole. Depending on the concrete project the different quadrants have to be wighted accordingly.

follow me on twitter, I need some friends :-)

.Net Quick Tip: Programmatic Check if a PDF Reader is installed

A possibility to programmatically check in .Net (with C#) if a pdf-reader is installed:

[TestMethod]   
public void CheckPdfReaderAvailable()    
{    
	RegistryKey key = Registry.ClassesRoot.OpenSubKey(".pdf");    
	Assert.IsNotNull(key);    
}

Checking if Excel is installed can be achieved the following way:

[TestMethod]
public void CheckExcelAvailable()
{
    RegistryKey key = Registry.ClassesRoot.OpenSubKey("Excel.Application");
    Assert.IsNotNull(key);
}

follow me on twitter, I need some friends :-)