Tuesday, June 28, 2011

Quotes of the Week: The Enterprise

quotes2.jpg

Events such as the Rails Rumble have shown that it’s possible to finish software projects in two days that might take a corporate development team weeks or months in a normal project scenario.



Scott: What is the penetration of Node.js into the "enterprise"?
Tim: It depends on what you mean by "enterprise"?
Scott: Large, slow moving corporations.


The corporate environments are awful!

 

In corporate environments the product don't have to be good. Sometimes they don't even have to exist ... if you are a thoughtful developer, you are in the wrong place!

 

Fear leads to Risk,
Risk leads to Process,
Process leads to Hate
... and suffering and Gant-Charts.
- Dan North, Keeping Agile Agile

 

Tuesday, June 14, 2011

Vacation Book & Screencast List

This is my book list for my current four weeks of vacation:

Bhh5 xlargecoverTbcoffee xlargebetaNrtest xlargecoverCfcar2 xlargecover51ZmBE4huJL BO2 204 203 200 PIsitb sticker arrow click TopRight 35 76 AA300 SH20 OU0151KQ2P7V1RL SL500 AA300

The last one I am taking along old-school-dead-tree, the rest I bought as ebooks to read on my kindle.

Also I am looking forward to watch the recent tekpub and peepcode episodes:

Ft sullivan slideMvc3 slideNode js coverPlay by play jbarnette titleEventmachinePostgresql

... as well the latest railscast episodes.

Saturday, June 11, 2011

Our NDC 2011 Slides: SpecFlow & BDD

Here are the slides from the two presentations Gaspar and I did last week at the Norwegian Developers Conference 2011.

The videos should be published soon on the NDC homepage.

Tuesday, June 7, 2011

Rethinking the Test Automation Pyramid

The Test Automation Pyramid is an analogy that is often referred when discussing test automation:
Pyramid orig WB
I believe the origin of this analogy is referred to Mike Cohn. At least he discussed it in the agile context in his post The Forgotten Layer of the Test Automation Pyramid. If you google for "testing pyramid" you find many derivations of the original pyramid picture. While preparing for our BDD presentations at the NDC, Gaspar and I were discussing the pyramid once again. And we also came to the conclusion that we want to redraw it:
Pyramid new WB
We found that we want to decouple test automation from architectural layering.
On the one hand we found that the tip of the pyramid is not always UI testing. Of course this depends on your definition of UI. But in a lot of systems I have seen interactive testing that is not really going through a UI (e.g. checking the print-layout of a report, checking if files are delivered on a share ...)
On the other hand we feel that with modern approaches (and tooling) automated UI testing can also be done efficiently in the middle layer of the pyramid to perform functional tests. The Rails/Capybara/Cucumber stack is a good example for this.

The next question is, if the functional slice of the pyramid should once again divided in different sub-slices. On the lower level there are automated Scenarios that usually fit to one feature of the system.
The ThoughTworks technology Radar from January 2011 mentions Journeys as a more holistic approach that describe and verify coherent functionality overarching individual scenarios. This will be an interesting concept to explore ...

Of course we were not the first to discuss this, there are other posts about this.

Friday, June 3, 2011

Help! They reproduce!!!

Kindle

Latest report from the friendly Kindle invasion ...

Wednesday, June 1, 2011

Thoughts: Are you too agile for TDD/BDD?

There was no requirement for Twitter!

Return on investment from software is far from certain.


Two recent blog posts seem to indicate that there are software development environments where core agile development practices like TDD and especially BDD do not fit. Those "high-ceremony" practices are even considered as waste:


Test-Driven Development and Embracing Failure
by Steve Freeman

Steve draws the difference between ordered and unordered domains and between fail-save and save-fail approaches.
TDD/BDD are fail-save approaches. We are assuming an  ordered domain: we know the relation between cause and effect and we can write specifications/expectations and we can verify them pretty reliably.
Here we have a "specify-verify" feedback-loop:
NewImage
In unordered domains we don't know the relation between cause and effect. Here it is pretty difficult to write specifications/expectations and to verify them a priori. It's mostly only possibly to gain insights after having been exposed to the "real world".
Here we have a "try-error" feedback loop:
NewImageThe most important thing is that the effects of failure will not have too bad and that you can react very quickly and make improvements based on the insights of those failures (and successes).
Agile is about embracing change. Some domains are best tackled by embracing failure.


The Dark Side Beckons?
by Obie Fernandez

Obie argues that classic web startups have to find their place in the market. The real test here is feedback that is gained from success (or failures) of the deployed app.
It's much more important to be testing against business metrics (user-count, ratings, click-throughs ...) than anything having to do with code. Those insights can only be gained from the market itself.
So the feedback-loop here goes not "spec-implement-verify" but it must include deployment and market response: "spec-implement-deploy-inspect".
Having an instant deployment pipeline is crucial to be able to react in this feedback loop.

My personal feeling is still that TDD (and even BDD) might make sense in the implementation phase of projects that tackle unordered domains.
I see that TDD/BDD in the sense of "discovering" behavior, in the sense of requirements gathering makes not much senese here. But they still help to ensure the correctness of the implementation, without a "correct" implementation, inspection makes no sense ...
But the "high-ceremony" aspect must be kept low and very pragmatic.
... however I might be clinging to my perception of the world... there are also people that claim that you can do agile development inside the phases of a waterfall...
Related Posts Plugin for WordPress, Blogger...