CLOSED-LOOP

BDD Breakfast in Zürich

2010-03-12T17:19:00.001+01:00

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

2010-03-11T00:42:00.002+01:00

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

2010-02-26T17:51:00.001+01:00

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

2010-02-26T00:10:00.001+01:00

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

2010-02-17T17:54:00.001+01:00

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

2010-02-12T16:49:00.001+01:00

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

2010-02-10T15:43:00.001+01:00

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 :-)

Swarm Programming - Scaling Pair Programming

2010-02-03T17:12:00.001+01:00

This is another tidbit from Dan North at the parkbench panel discussion on the Agile Testing, Specifications and BDD exchange.

If I remember correctly the topic of the discussion was about the topic if software engineering is really an engineering discipline or rather a craftsmanship:

Are you sure that what you do is software engineering? NASA is doing software engineering!

In commercial software the average cost for a line of code is estimated at 5$.
At NASA the average cost for a line of code is 5'000$.

They are not just Pair Programming, what they do could be called Swarm Programming!

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

How to debug your code with cuke4duke

2010-02-02T22:55:00.001+01:00

Cuke4duke is a ATDD/BDD tool for the JVM. The tool is based on Cucumber and uses JRuby to execute.

Out of the box cuke4duke offers three main ways to execute: Ant, Maven or cuke4duke-commandline.

But all of those three approaches are a bit tricky if you want to debug your application when executing in a BDD scenario.

There is some information on the wiki how to achieve it.

Here some more details:

Maven and Remote Debugging

When using Maven, you can add the following lines to your cuke4duke config in your pom.xml:


<plugin>
  <groupId>cuke4duke</groupId>
  <artifactId>cuke4duke-maven-plugin</artifactId>
  <configuration>
    <jvmArgs>
      <jvmArg>-Dcuke4duke.objectFactory=cuke4duke.internal.jvmclass.PicoFactory</jvmArg>
      <jvmArg>-Xdebug</jvmArg>
      <jvmArg>-Xnoagent</jvmArg>
      <jvmArg>-Djava.compiler=NONE</jvmArg>
      <jvmArg>-Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y</jvmArg>
    </jvmArgs>

(a running example is here)

When you now run the integration-test phase (ie. mvn verify), then Maven breaks and waits for a debugger to connect:


[INFO] [cuke4duke:cucumber {execution: run-features}]
[INFO] Listening for transport dt_socket at address: 4000

Now you can connect with Eclipse with a new debug configuration (Run->Debug Configurations...). Choose 'Remote Java Application' and configure the same port as you configured in the pom.xml under address:

Now execute this debug configuration, and Maven (which is still waiting) will continue after Eclipse successfully connected, and any breakpoints you set in Eclipse will trigger.

Running from the IDE

Another way is to execute the whole enchilada (JRuby, cuke4nuke, cucumber…) directly out of the IDE. In Eclipse this is accomplished with a new Debug Configuration. Choose Java Application then configure it accordingly: Main class: org.jruby.Main

Program Arguments:

${M2_HOME}/repository/.jruby/bin/cuke4duke ./target/test-classes features

VM Arguments:

-Dcuke4duke.objectFactory=cuke4duke.internal.jvmclass.PicoFactory

Classpath: Make sure all needed jars are on the classpath.

Now execute this debug configuration and Eclipse will break directly at any breakpoint you set in your sources.

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

Podcast: Scrum in Fixed Price Projects

2010-02-01T21:41:00.001+01:00

In the first episode of TechTalk's podcast Christian Hassa interviews Mitch Lacey about the applicability of Scrum in fixed price projects.

They talk about common misconceptions, pitfalls and dangers and how to avoid them. Mitch also presents some patterns that worked in his experience.
The podcast is in english.

You can download the podcast directly or subscribe to the rss-feed or subscribe to the podcast in itunes.

BTW: For people living in Switzerland or Austria: This February Mitch is holding his Certified Scrum Master courses in Zürich (8.-9.03.2010) and Vienna (11.-12.03.2010).

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

Lessons Learned from Java EE

2010-01-27T18:40:00.001+01:00

Lessons Learned from Java EE is an interesting presentation by Rod Johnson.

Here the most interesting/provoking points:

The fallacy of love for complexity: "No pain no gain" does not apply for software. Powerful solutions do not have to be complex, the opposite is true!

Tools cannot conceal excessive complexity!

The myth of the code monkey: Developers are dumb. They have to be protected from having to make decisions. -> The result is excessive complexity.

The need for an over-arching (enterprise) strategy means that common sense is thrown out the window.

Complexity is an expensive luxury - in economic boom times people are happy spending money for complexity but economic downturns tend to reduce complexity.

Developer empowerment is an ongoing trend:
- Because things change quicker than in the past, and management need to rely on developers more
- Open source allows participation
- Expensive, complex portfolio solutions/tools did not prove to be successful/productive
- Agile development is a developer-led initiative
- The Cloud is shifting the balance between operation and development

My posts around these topics:

	The Antipattern of Framework- vs. Business-Programmers			Essential, accidental and fabricated complexity
	Visual modeling: Is it worth it? An example...			Creativity and competent People
	Michael C. Feathers: Seven Blind Alleys in Software Design			Java EE: The blue pill of enterprise development?

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

Scrum Master Certification in Zürich with Mitch Lacey

2010-01-26T21:11:00.001+01:00

February 8. and 9. Mitch Lacey is running his Scrum Master Certification course in Zürich Switzerland.

If you are thinking about getting the Scrum Master Certification, I can fully recommend Mitch's course.
I did attend his course in Vienna last autumn. Those two days were very interesting, informative and never boring. Mitch really is a great teacher and story teller with a lot of practical experience.

If you are interested you can find more details and registration here.

Update: On TechTalk's Mind hosts a podcast with Mitch discussing Scrum in fix-price projects.

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

The risk of scrum

2010-01-07T23:06:00.001+01:00

Last month Ralph Jocham gave a talk about the Risks of Scrum.

He published the slides on slideshare: Ralph Jocham The Risks Of Scrum.

As far as I understood it, Ralph identified two Risks with Scrum:

Not doing it right or not practicing it to the full extent
Neglecting technical excellence and accumulation of technical dept

The first one is a bit a platitude in my opinion. Any failure can be blamed on not doing things right... of course with methodologies that consist of several parts, there is a danger of cherry-picking, but I am not sure that this can't work. I think it's also often a cheap excuse to put the blame for a failure on "not doing it right". I mean, who is really doing it right? How many of the successes are doing it right?

According to Ralph the second risk should be met with XP practices that focus on technical quality.

But in my opinion there is a much more fundamental danger in scrum:

Scrum gives the impression that it is possible to bring "Embracing Change" and "Getting Things Done" under the same umbrella.

This is dangerous. "Embracing Change" and "Getting Things Done" are two opposing forces. On a certain level it is inherently not possible to get things done while embracing change.

Scrum as an agile methodology is all about embracing change. With the focus on the Done-Stage on the Taskboard and the "Definition of Done", Scrum claims that those two opposing forces are actually not opposing. This is in most cases an illusion.

This is mostly a result of focusing on small stories with immediate business value. Getting these stories done is possible, and Scrum can easily misused as an "excuse" to neglect the big picture.

Progressing in Scrum means getting stories done. Often the real progress of a finished story in regard of the whole project is not measured...

A symptom of this antipattern is that certain things get touched and changed again and again by new stories in subsequent sprints... so what was actually done, the story or the real business problem?

Shortening sprint duration and focussing on smaller user stories can even aggravate this problem ...

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

Testing Backlash: Recent, well grounded opinions questioning the value of TDD and unit-testing

2010-01-04T19:25:00.001+01:00

It is 2010. I declare that #TDD is no longer controversial.

Uncle Bob Martin on Twitter

We all know the Gartner Hype Cycle for technology adaption:

Sometimes I wonder where on this curve we are concerning unit-testing and Test Driven Development (TDD)?

Just recently there seem to be a movement to the "Through of Disillusionment" with several fairly well grounded articles questioning the value of unit-testing and Test Driven Development (TDD):

Problems with TDD an Essay by Andrew Dalke. Heavily discussed on his blog and on Hacker News.

Chris Ashton's post: It's OK Not to Write Unit Tests

Ayende's posts: Even tests has got to justify themselves and re: Are you smart enough to do without TDD

And finally Luce Francis brilliant presentation: Testing is Overrated (matching blog post, slides)

On the other hand there seems to be prove that TDD is valuable:

Empirical Studies Show Test Driven Development Improves Quality

Maximilien-Williams study

Uncle Bobs TDD Triage

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

Computer Science vs. Software Engineering

2009-12-31T13:29:00.001+01:00

I listened to SE-Radio Episode 149: Difference between Software Engineering and Computer Science with Chuck Connell.

Interesting stuff...

The most insightful thing was that historically we put too much unrelated things into the same bucket:

Computer Science vs. Software Engineering

Algorithms, Cryptography, Compilers vs. Business Applications, Consumer Applications

Complexity Analysis, Correctness Proofs vs. Maintainability, Testability

Formal Specifications vs. Estimation

Language Syntax/Semantics vs. Design Patterns

More background is in Chuck Connells article on Dr.Dobb's. Including The bright line in computer science:

This once again leads back to the question: What is software engineering?

Art?

Craftmanship?

Science?

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

Bug Driven Development: Samurai Debugging Reinvented

2009-12-30T15:50:00.001+01:00

In his presentation about Behavior Driven Development (BDD) and Domain Driven Design (DDD), Dan North talks about another interpretation of "BDD": Bug Driven Development or "DDD": Defect Driven Development.

It goes like this:

The customer comes to the developer and wants the perfect system. He describes what he wants, but its this fuzzy vision described in a business language that the developer just is not able to grasp...

The developer: "Ah ok... I understand. It is done!"

Customer: "What? What do you mean?"

Dev: "Well it is done. The system is finished!"

Customer: "Well, no ... I don't see an icon where I can start the system?"

Dev: "Oh! You are right. That's a bug! I will fix it."

... five minutes later ...

Dev: "Ok, the icon is here. Now it is done!"

Customer: "Well, no! When I double-click the icon nothing happens!"

Dev: "Oh! You are right. Thats a bug! I will fix it."

... five minutes later ...

Dev: "Ok, the the app starts when you double click. Now it is done!"

Customer: "Well, no! There is nothing in the newly opened window!"

Dev: "Oh! You are right. Thats a bug! I will fix it."

... you get the idea.

While this is a humorous story, it actually demonstrates the qualities that BDD (now Behavior Driven Development again) strives for:

Pull based instead of push based: The developer pulls new requirements from the business just in time when they are needed.

Outside-in: The development is driven by the business relevant features that are actually used and matter to the stakeholder.

Constant involvement of the customer.

Small steps with clear acceptance criterias.

Another analogy is funny: Behavior Driven Development is an evolvement from Test Driven Development, taking the concepts of the latter to a higher level, evolving out of a purely developer-centered discipline.

The same could be said for Bug Driven Development: The concept of Samurai Debugging was already a humorous technique in Extreme Programming:

When you follow the Samurai Debugging technique, you start with a blank screen. That's not what you want, so you start debugging it, and you continue debugging it until your program does exactly what you want it to do.

from Extreme Programming Refactored

Now Bug Driven Development takes this to the next level by involving the customer :-).

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

Java vs. Net: Web Frameworks

2009-12-29T19:23:00.001+01:00

Quantity is the real difference:

Humorous episodes following from this:

Trolling with Java Web Frameworks.

I don't think you can count someone even as a semi-decent java dev until he wrote his very own web framework at least once in his life (from here)

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

Code Monkeys do exist: I knew it!

2009-12-28T12:42:00.001+01:00

Ever felt like a Code Monkey?

Then Primate Programming Inc might be the company for you...

"Humans and higher primates share approximately 97% of their DNA in common. Recent research in primate programming suggests computing is a task that most higher primates can easily perform. Visual Basic 6.0™ was the preferred IDE for the majority of experiment primate subjects."

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

Definition of Behavior Driven Development

2009-12-24T10:11:00.001+01:00

I updated the entry for Behavior Driven Development on Wikipedia.

On the Agile Testing, Specifications and BDD exchange Dan North gave an updated definition of BDD in his talk:

BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.

Watch his talk for an explanation of this definition...

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

Maven gets partially absorbed by modern JVM languages …

2009-12-23T19:40:00.001+01:00

Maven has a lot of interesting and useful ideas, but its usage is often over-complicated and several concepts are too much entangled. (examples: 1, 2, 3)

The foremost feature of Maven that comes to mind is probably dependency management. Maven probably standardized dependency management for the Java platform. That’s probably also the reason for its wide adoption.

At this time there are already several attempts for smaller and easier solutions that repackage the ideas about dependency management from Maven. Their promise is to be a cleaner and easier to use.

Foremost there is Ivy, which provides Maven-like dependency management for Ant.

There are even two JRuby projects that bring simplified Maven-like dependency management to the JVM: maven_gem and javagems.

Especially interesting is Grape, which provides dependency management for Groovy at a language level (by integrating Ivy).

I think these examples are an impressive demonstration how the Java platform grows and how good ideas and concepts are adapted and evolved.

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

Challenging Requirements Video

2009-12-21T19:04:00.001+01:00

Definitely the most entertaining presentation (closely followed by Dan North's) at the Agile Testing, Specifications and BDD exchange was Gojko Adzic's "Challenging Requirements".

You can watch a video of his presentation on his blog.

I can also recommend Gojko's latest book: Bridging the communication gap.

It is a very good resource for learning ATDD and BDD.

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

Poignant statements about our profession

2009-11-16T23:22:00.001+01:00

Jay Fields has a poignant but concise style to express his opinion.

Currently my two favorite quotes are:

We're still figuring this stuff out. All of us.
Thoughts on developer Testing

and

When no one knows what's "correct", people with confidence generally win the discussion.
Programmer Confidence and Arrogance

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

A note to all software project stakeholders: Remember it is not christmas!

2009-11-11T01:44:00.001+01:00

http://www.flickr.com/photos/gracefamily/ / CC BY 2.0

Peter Stevens hit the nail on the head at the SAQ Software Tester Forum 2009 last week:

You won't get everything you want!

That's a fact. Accept it.

Actually you can get everything you want if you have unlimited time and money. But since that is not the case in todays software projects (maybe there are exceptions?), we have to make tradeoffs.
And that is where the strength of Agile Software Development comes into play.

Agile advocates constant feedback and prioritization. Together with the 'good enough' and YAGNI principles this helps to create better usable systems within budget and time constraints (eliminate waste in the lingo of the lean).

Peter Stevens then talked about how goals can still be achieved, even without getting everything we want. His presentation can be downloaded here.

Later on, in an interesting conversation Andy Palmer pointed out that even when a MoSCoW (Must, Should, Could and Won’t) analysis is done, still a lot of projects finally only deliver a fraction of the actual 'Musts' ... and are still considered as a success. What does this tell about our prioritization?

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

Testing: Chances and Challenges in an Agile World

2009-11-09T18:52:00.001+01:00

Last week I gave a presentation on the SAQ Software Tester Forum 2009:

Testing: Chances and Challenges in an Agile World (most slides in english...)

View more documents from jbandi.

Update 2009-11-11: Here are some pictures of the event.

The stage for my presentation was very well set by Andy Palmer and Peter Stevens who talked both about Acceptance Test Driven Development and about Agile Development in general.

In the afternoon there were several discussion sessions. Generally people wanted to know what the major changes there are in agile projects concernig testing.

A lot or the participants were very eager to affirm that Agile does not change anything concerning testing. Somehow I got the feeling that there was a fear that Agile is claiming that traditional testing is somehow outdated or superfluous...

In my opinion this is definitely not the case. Solid testing practices and processes are even more important in Agile projects. What changes is the timeline! This however has implications on the amount of work (a lot more test effort aggregated over the whole project) and it is a challenge for tester how to deal with this. But it does definitely not change that testing in all flavors (automated, manual, guerillia ...) is still a must.

If I look at requirements engineering, development and testing as three separate disciplines in software projects, then I would argue, that Testing is actually the discipline that is the least affected by Agile.

Most of the participants however were very focused on their current situation and activities and not seeing the big picture. Tests to assert quality is and will always be important. But testing can be more than quality assurance! Tests can be leveraged to prevent defects. Of course this is not necessarily bound to Agile, but Agile explicitly supports those notions.

One consequence of these ideas however is that developers and testers have to interact intensely and there is no place any more for traditional boundaries between testers and developers! Agile promotes multifunctional teams. This however does not mean that there are no specialized testers any more, but they are part of the same team as the developers and all have the common goal of producing useful software. Games of queen of spades between developers and testers definitely have no place in an Agile project!

In the final panel discussion Peter Stevens pointed out another perspective, that shows that testers can greatly profit from Agile: In traditional enterprisey environments the salary curve is usually inverse proportional to the distance to the customer. Testers sit at the end of the chain, with the greatest distance to the customer. This setup can change drastically with Agile ideas like formulating Acceptance Tests with the customer, moving Acceptance Tests to the beginning of development and driving development with Acceptance Tests. Open minded testers can seize this chance and redefine their role in the organization hierarchy!

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

Quick Tip: Running Selenium on OS X Snow Leopard

2009-11-02T22:16:00.001+01:00

Probably it is not only a Snow Leopard thing. But I stumbled over the following problems when running Selenium on OS X:

With Safari 4.0.3: Pop-up blocking is default on, switch it off:

With Firefox 3.5.3:
I got the following error from the selenium server:


dyld: Library not loaded: /usr/lib/libsqlite3.dylib
  Referenced from: /System/Library/Frameworks/Security.framework/Versions/A/Security
  Reason: Incompatible library version: Security requires version 9.0.0 or later, but libsqlite3.dylib provides version 1.0.0

This problem was fixed with copying a newer version of the library into the firefox installation:


mv /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib.orig
cp /usr/lib/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib

(First command is just for backup. Tip found here)

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