CLOSED-LOOP

Oracle vs. Google reminds me of Matrix Revolutions

2010-11-03T01:04:00.004+01:00

Ha ha ha ...

All that talk, predicions, more talk and conspiracy theories around the Oracle vs. Google lawsuit and it's meaning for Java reminds me somehow of the time right after Matrix Revolutions when everybody was speculating about the plot of the third movie Matrix Reloaded. (Why can Neo control the sentinels in the real world, why can Smith take the body of a real human, what did the architect really mean ...)

There were actually people that spun up plots for Reloaded that were much better* than what finally turned out to be the disappointing end of the trilogy. I guess the same is true for the current wild theories where Java is heading ...

... somehow I suspect that the same that happened to Matrix Revolutions will happen to all the fuzz and expectations about where Java is heading: A year from now nothing will have changed substantially (Revolutions was not worthy to be connected to the first Matrix movie) and nobody will talk about it any more.

Much ado about nothing!

*search for neo2083

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

M-V-VM: It's not a pattern, just a mess!

2010-04-13T18:04:00.001+02:00

Ok, I am being provocative here:

After attending LBugnion session "Das “Model-View-ViewModel” Entwurfsmuster" at the TechDays last week and now watching DNR-TV episode 161: Rocky Lhotka on the MVVM Pattern in CSLA .NET 3.8, I now dare to claim that:

The Model-View-ViewModel pattern is not a pattern!

I have been confused for a long time.

Now I have come to the conclusion that I will stay with the classic presentation patterns and Fowlers discussion: MVC, MVP, Supervising Controller, Passive View, Presentation Model.

Those concepts are quite clear and provide a sufficient vocabulary to discuss architecture and design of the presentation layer of an application. There is nothing to M-V-VM that provides additional concepts that are not covered by the former patterns.

For Model-View-ViewModel I have just seen too many varying ideas, too many different concepts and too unclear explanations. So I can't accept it neither as an architectural- nor as a design-pattern.

The fact that in the Java world the notion of this pattern is nonexistent is also an indicator that this can't be a fundamental concept in software development (though technologies like xamlwpfsilverlight might legitimate the need for new patterns).

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

Classifying BDD Tools (Unit-Test-Driven vs. Acceptance Test Driven) and a bit of BDD history

2010-03-31T00:37:00.005+02:00

BDD (Behavior Driven Developement) seems to gain momentum lately.

BDD is hard to grasp, because it is more than a development methodology (unlike TDD) and there are currently very different ideas what it really means. To make matters worse there are a lot of BDD tools around that pursue quite different concepts.
In this post I try to classify two main categories among those tools.

Important for the understanding is that BDD can be practiced at different levels. At the code/unit level and at the feature level. In both cases it is a good practice to use examples to specify the behavior of the units resp. features. However in both cases we have different stakeholders and intents with the BDD process.
Both approaches to BDD are not exclusive, they can be combined.
(see also "BDD for Acceptance Tests vs. BDD for Unit Tests (or: ATDD vs. TDD)" on the SpecFlow mailing list)

Currently I would differentiate two flavors of BDD tools:

Tools with a business readable output
Tools with a business readable input

With tools from the first category (business readable output) the support for the BDD process is typically focused on the developers. All artifacts involved are owned by the developers and are typically code. This is not a bad thing, as responsible and committed developers are often the main stakeholders in successful software projects. Other stakeholders are only addressed by the tools by providing understandable reports after developers have done their work.

Tools from the second category (business readable input) try to widen the focus of the BDD process by enabling more involvement by all other stakeholders: customers, business analysts, testers maybe even operations.
This involvement is possible upfront, meaning before the developers have done their work. This business readable input is an artifact commonly owned by all stakeholders. By having a commonly owned artifact, the process tries to ensure that all involved stakeholders build up a shared understanding which is crucial for successfully software projects (for more information I suggest reading Bridging the Communication Gap by Gojko Adzic).

Because this shared understanding is input (as opposed to output) and business readable, the process can even be taken further and make the artifact business writable. If this is achieved successfully then we have done a big step towards executable specifications.

In practice we often see tools of the first category (business readable input) used as a replacement/extension for TDD at a unit-testing level.
In this case the behavior of the unit under development is focused by trying to specify this behavior upfront in a less technical way. However this is usually not interesting for other stakeholders than developers, because the technical units under development are usually too fine grained and have no meaning to non technical persons. Also technical units are the primary focus of developers and they are the main stakeholders (think of testability, separation of concern, maintainability ...), other stakeholders should not be too involved here. So this is mainly a tool for developers and allows in some cases the mapping of technical units to overlying features.

The second kind of tools aim clearly at Acceptance Testing and Acceptance Test Driven Development. Here system features are clearly focused. Features are usually more coarse grained than the behaviors of single technical units. Features should always be understood and driven by business requirements.

It is certainly possible to write acceptance tests with the first category of tools, but the driving aspect (as in Acceptance Test Driven Developement) is certainly harder to achieve and less supported by these kind of tools.

Examples:
Easyb is a Groovy based tool of the first category. The following example (from this post) shows how behavior is specified at at unit-level (class-level):

scenario "Two amounts with the same currencies are added", {
  given "Two different amounts with the same currencies", {
    money1 = new Money(12, "CHF")
    money2 = new Money(14, "CHF")
    expected = new Money(26, "CHF")
  }
  when "Add given amounts" , {
    result = money1.add(money2)
  }
  then "New amount is sum of two given ones", {
    result.equals(expected).shouldBe true

}
}

scenario "Two amounts with different currencies are added", {
  given "Two amounts with different currencies", {
    money1 = new Money(12, "CHF")
    money2 = new Money(14, "EURO")
  }
  when "Add given amounts", {
    add = {
      money1.add(money2)
    }
  }
  then "Operation should fail", {
    ensureThrows(IllegalArgumentException) {
      add()
    }
  }
}

Executing the above story gives you the follwowing readable report:


2 scenarios executed successfully.

  Story: money

    scenario Two amounts with the same currencies are added
      given Two different amounts with the same currencies
      when Add given amounts
      then New amount is sum of two given ones

    scenario Two amounts with different currencies are added
      given Two amounts with different currencies
      when Add given amounts
      then Operation should fail

(of course easyb can also generate a fancy html report)

Cucumber is a tool of the second category. The following example from cuke4duke shows how an executable feature is specified:


Feature: Book search
  In order to find books I might buy
  As a potential customer
  I want to search for books by different criterias
  
  Background:
    Given the following books
      | Author          | Title                                           | Year | Publisher      |
      | Martin Fowler   | Patterns of Enterprise Application Architecture | 2002 | Addison Wesley |
      | Eric Evans      | Domain Driven Design                            | 2003 | Addison Wesley |
      | Gerard Meszaros | xUnit Test Patterns                             | 2007 | Addison Wesley |
  
  Scenario: Search for title
    When I search for title 'Patterns'
    Then the result list should contain 2 books
  
  Scenario: Search for author
    When I search for author 'Fowler'
    Then the result list should contain 2 books

(notice the error in the second scenario!)

When executing this example (using cuke4duke) the whole EJB stack is exercised, including database-access. The result is the following report:

(of course Cucumber can generate a lot of different outputs)

History (as I could reconstruct it):
Tools from the first category evolved from TDD. Dan North introduced BDD in 2002, see his introductory blog post.
JBehave was one of the first BDD tools, at this point clearly part of the first of the above categories.
Then the BDD movement was mainly driven by the Ruby/Rails community. RBehave was introduced and then merged into RSpec as RSpec Story Runner.
RSpec then was as a tool that could satisfy both of the above catgories

RSpec StoryRunner was then dropped and Cucumber was created. Cucumber coined the current flavor of BDD tools with plain-text specifications. Cucumber also is aiming at extending its reach beyond Ruby/Rails (see cuke4duke, cuke4Nuke, gherkin).
Other first-generation tools then adapted and also support plain-text specifications (JBehave2, NBehave).

Beside all those explicit BDD tools there is FIT/FitNesse. FIT was also invented in 2002 by Ward Cunningham. Its goal was enabling collaboration and communication through automated accepatance testing. FitNesse took up the basics of FIT and provided an intuitive, wiki-based frontend/IDE.
While FIT seems to have practically died, FitNesse is still thriving. FitNesse also recently added Parameterized Scenario Tables and there is GivWenZen. This makes it possible to use the plain-text GWT (Given-When-Then) syntax, that was made popular by the plain-text BDD tools.

I will list a more complete overview of BDD tools for the Java and .Net platforms in later posts.

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

Parkinson's Laws

2010-03-18T00:16:00.002+01:00

I only recently stumbled over Parkinsons Laws, even though I think in the IT business we are constantly confronted with them:

Parkinson's Law:

Work expands so as to fill the time available for its completion.

Who has not seen self fulfilling estimations?

Parkinson's Law of Triviality:

Organisations give disproportionate weight to trivial issues.

(the time spent on any item of the agenda will be in inverse proportion to the sum involved.)

Think of this next time you are on a meeting discussing the pros and cons of using underscores as prefix for member variables ...

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

The Agile Testing Quadrants

2010-02-12T16:49:00.002+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 Marick, 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 :-)

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

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

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

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.002+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)

Update: 2010-11-14: For Firefox 3.6 make sure that you are upgrade to the latest version of selenium-server. I just wasted some hours trying to get firefox running with selenium-serve 1.0.1. The problem disappeared with selenium-server 1.0.3.

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

Learned today: Scrum is like a roundabout

2009-10-01T22:24:00.001+02:00

Yesterday I was attending the scrum breakfast in Bern.

François Bachmann held an insightful presentation where he drew analogies between traffic and software projects: Projektstau auflösen - wie Sie Ihrem Manager Agilität erklären können (Breaking up traffic jam - how you can explain Agile to your manager).

The main analogy was:

Scrum is like a roundabout

Simple & Transparent Concept

Based on the Pull principle (not Push)

Provides Feedback

Self-organising mechanism

Heavily relies on discipline and personal responsibility

Roundabouts cause uncertainty and precaution at first contact (if you are used to traffic lights - command & control style).

Roundabouts are optimized for local decisions (only precedence from one direction is relevant) - traffic is too complex for exact planning and influenced by unforeseeable events, only high level planning is feasible, details have to taken care of when they happen.

A lot of decision-makers with potential different interests are involved

Individual decision-makers have only incomplete informations

Roundabouts work as well for rush-hours as for no-traffic situations

Benefits: less conflict, higher safety, optimized throughput, reduced waste, reduced costs, calm & aesthetic

(http://www.sandiego.gov/planning/programs/transportation/pdf/roundabout.pdf)

Problems: Not appropriate for some situations (highway crossing a footpath), requires space, needs getting used to

And a funny example of scrumbut:
Arc de Triomphe - a roundabout, but entering vehicles have precedence.

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

Retrospective: JPA Workshop /ch/open

2009-09-30T22:59:00.001+02:00

Simon and I gave our JPA Workshop at the workshop days of /ch/open earlier this month.

Now the course feedback is online. I think generally we can be content, especially the comments are pleasant. The participants seemed to like our examples.

All the content (slides and examples) is available as project jpaworkshop on Kenai.

I am looking forward to repeating the workshop next year. By then the JPA2 implementations should be finished.

Note to myself - things to look into for the next time:

Using EclipseLink JPA Extensions for Entity Caching

Understanding EclipseLink Caching

Queries and the Cache

EclipseLink/Examples/JPA/Pagination -> still supporting only Oracle?

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

Abstraction, Encapsulation and social Darwinism (The Antipattern of Framework- vs. Business-Programmers)

2009-09-29T12:50:00.001+02:00

Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.

- Eric Evans at SET 2008

Hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job.

- Educate Developers Instead Of Protecting Them by Davy Brion

Making development "safe" for lesser skilled developers by taking choices away from developers [...] does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I'll say that there is a silver bullet(s), it's: Skill. Knowledge. Experience. Passion. Discipline.

- Jeremy Miller

Again and again I come across projects, teams and companies that misuse the concepts of Abstraction and Encapsulation to establish a two class society among the developers.

In those setups you usually find on one side a framework-team that is responsible for a supposedly productivity-boosting, supposedly well crafted framework / platform / infrastructure. On the other side you find an army of business programmers that have to use the provided framework / platform / infrastructure to actually realize business value.

Usually the framework-team members think of themselves as the gurus, the elite, the "real" programmers, while the business programmers are considered as "lesser" foot soldiers.
These attitudes are mostly shared and therefore promoted by management. Indeed the framework-programmers often have the better education and/or more technical expertise.
If the situation is really bad then the framework team does not like to mingle with the business-programmers and the worst thing is, when they are not even co-located.

I heavily oppose this setup. It is an antipattern, that prevents team enabling. Agile, self-enabling, highly-motivated teams will never evolve in such a structured and divided team setup. This is not an environment where individuals are allowed to grow, this is an environment where employees are assigned! In such an environment, people just start to not care any more: framework-developers do not really care about business value, business-developers dont't feel like being able to make a difference...

As I don't believe in the factory analogy, I don't believe there is a situation where lesser developers have to be shielded/protected by a technical framework. The time to create a patronizing framework, would be better invested in teaching and exchanging knowledge.
In my experience, if a developer is not productive, then this is usually a management failure. Simple measures like assigning another task, changing the setup, pair programming, coaching, reviews etc. would usually improve the situation. I have seen projects where this has been achieved successfully, but in the above setup, this is usually not going to happen.
And in the rare case that you are really dealing with a net negative producing programmer (NNPP), no technological solution will save you... Abstraction and Encapsulation are pillars of object-oriented design. They are intellectual constructs to tackle complexity. They are technical tools and not a mechanism to legitimate team structure.

Using engineering techniques from object-oriented design to enforce team structure and separation feels just as wrong as applying Darwin's evolution theory to human societies.

Possible remedies and counter measures for the situation are:

Eat your own dogfood: Framework-developers have to use their own framework. They have to be involved in business-programming.

Empower the business developers: Establish an environment where it is absolutely clear, that the business developers are the ones that are providing value. The framework-team has the sole purpose to enable the business-developers.

Productize the framework: Nobody is forced to use the framework. The framework-programers have to actively sell their work, the business developers can freely decide if they want to use it. (According to a disscussion with Mark Striebeck, this philosophy is very successful at Google)

Collective ownership of the code, including the framework.

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

Illustrative Programming: I am a skeptic! (and I am not alone)

2009-09-22T16:16:00.001+02:00

I have stated several times, that I don't believe in visual modeling and cannot share the enthusiasm that a certain branch of MDSD people have for visual modeling:

Visual modeling: Is it worth it? An example...

Musing about Code Generation, MDSD and DSLs

Now Martin Fowler is coining the Term "Illustrative Programming" in the context of Language Workbenches like IntentionalSoftware, which are tools to build "illustrative DSLs".

For a lot of people coming from the UML camp, the notion of a "DSL" is what Fowler is calling an "illustrative DSL" here. Visual Studio Domain-Specific Language Tools are a striking example of this.

In his article Martin Fowler quotes some opinions of Neal Ford about the concepts of Illustrative Programming:

I think these tools work best for lay people (thus, your link to LayProgrammers). However, in general, tools like this slow down experienced/power users. [...] I would much prefer a markup language I could use to directly define stuff, with macros, snippets, and all the other things I'm accustomed to as a developer.

As these tools grow, they get unwieldy (perhaps because they are ceasing to be domain specific enough?). [...] APIs in programming languages scale much better, with several orders of magnitude more density before they become hard to navigate.

All the best-practices and tools don't exist there: refactoring, levels of testing, etc. Also, you loose the connection to text, meaning that macro facilities either don't exist or complex one-offs. [...]

I share your bullishness around these types of tools, but they are a long time from being useful for full-bore Agile development. I hope they mature fast.

Reading these comments, I am having a deja-vu!

This is really expressing what I was feeling when I was involved in MDSD attempts in recent projects. I don't generally doubt the noble goals that the visual modeling camp believe in.

But the tools and environment are just not ready to provide value. At least not in that kind of mainstream real world enterprise projects I have been involved in.

Also in my experience, the target of illustrative programming is the developers, which is wrong!

As Fowler is pointing out, the goal of illustrative programming is to engage lay-programmers.
Developers need other tools than lay-programmers! So if there are no lay-programmers in your project, there is arguably need for illustrative programming...

This insight was always lacking when I was confronted with attempts at visual modeling.

It is a common mistake in a lot of projects to establish some kind of two-class society among the developers, in this case it could be tempting to degrade the second class to lay-programmers. But that is a sick environment to begin with (and the topic for another post)...

of cource you should follow me on twitter