Swarm Programming - Scaling Pair Programming

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

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

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

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

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

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:

1. Not doing it right or not practicing it to the full extent
2. 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

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