This is my Software Craftsmanship Pecha Kucha from the XP Days Germany 2009. Since a Pecha Kucha simply consists of 20 pictures and some text in 20 seconds, I decided to put the pictures up here directly. Additionally I translated the text from German to English (via Google Translate)
Continue reading Software Craftsmanship Pecha KuchaCategory Archives: Methodologies
Methodologies
Cultural Infections
Beside the flu there is another infection which you may get – at your day-to-day work. Cultural habits may be a decease in some organizations. Here are some of my experiences with these cultural infections and how one can vaccinate.
Continue reading Cultural InfectionsQuality is not dead
Half a year ago James Bach began with a blog series about Quality is dead. I tried to get a handle on it some time ago, but there is still something striking about quality and the fact that I don’t support James’ Hypothesis.
Continue reading Quality is not dead“The biggest defect is tolerating defects.”
The headline is a quotation of Mary Poppendieck from her keynote at the Agile Testing Days conference in 2009 in Berlin. Today while reading through Jerry Weinberg’s Quality Software Management Vol. 1 I understood why.
Continue reading “The biggest defect is tolerating defects.”Size/Complexity dynamic and Agile adoption failures
With the help of Jerry Weinbergs description of the size/complexity dynamic in Quality Software Management Vol. 1 – Systems Thinking, I think I found an abstraction to Cockburns reasoning on the failure of Agile adoption.
Continue reading Size/Complexity dynamic and Agile adoption failuresAgile Testing Days Berlin V – The final day
Agile Testing Days Website
On the final day of the Agile Testing Days my presentation was due. Since it was my first conference presentation ever, I was very stagefright about the course. Though, here is my write-up on the other presentations I visited.
From the Definition of Done to “Are we done, yet?”
In the dialog about my recent blog entry about the Definition of Done, I was able to refine my mental model about “Done”. Here is a write-up of it.
Continue reading From the Definition of Done to “Are we done, yet?”My Definition of Done
Over the course of the Agile Testing Days I noticed that the definition of “Done” is troubling for Agile teams. It was not only raised in the Tutorial I took, but also on several key note speeches and there were several presentations that also dealt with it. Personally I was wondering why. During the last three days I thought “Done” simply means that you can make money with it. Sounds like an easy definition, isn’t it? If your customer or product owner is not willing to pay money for the user story implemented, it’s not “Done”. Period.
But today I came up with another, easier definition of “Done”, which was strikingly easy to realize in the end. For the definition let me put together several influences from Elisabeth Hendrickson, Adam Goucher, Kent Beck, and many more to a remarkably easy combination.
Elisabeth Hendrickson told me that “Done” simply means implemented, tested (or checked as Michael Bolton defined it) and explored. Very easy, isn’t it? But there’s more to it. Implemented means it is designed, and written in probably some programming language, right? Does this make sense? Considering my visit at the Software Craftsmanship Conference in February I noticed that it seems to be accepted – at least for the crafts people I met there – that implementation means to do it using Test-Driven Development. There was no discussion and arguing about this, it was simply taken as a fact and it was done in a TDD-style. But, remembering back Kent Beck TDD means Red – Green – Refactor, right? A three part meme, oh another one. Great.
The next term in Elisabeth Hendricksons definition of “Done” is tested (or checked). Considering current approaches to get the customer’s requirements using an Acceptance Test-Driven Development style, I would like to coin tested to mean, that we agreed on examples to implement and these examples serve as acceptance criteria in an executable manner. So, actually tested here means, that the code was able to pass the acceptance tests which were agreed upfront onto and were elaborated maybe by the testers on the project to also contain corner cases, which were missed. On Monday Elisabeth Hendrickson taught me, that ATDD can be thought of as Discuss – Develop – Deliver. Gojko Adzic corrected this over twitter to Describe – Demonstrate – Develop. But what do we have here? I claim that tested (or checked) here refers to ATDD style of development, which is itself again defineable as a tricolon itself. So, wrapping up, we have
- Done is Implemented using TDD, Tested via ATDD and Explored
- Implemented using TDD is Red – Green – Refactor
- Tested via ATDD is Discuss – Develop – Deliver
(Forgive me Gojko, but I find Elisabeth’s definition more intuitive to remember.)
Oh, I got one more. Explored clearly refers to Exploratory Testing. It actually might be a coincidence, but Adam Goucher came up with a definition of Exploratory Testing today in a tricolon manner, too: Discover, Decision, Action. Sounds reasonable to me. During Exploratory Testing we discover information about the product which we previously did not know. Based on the information we decide what to do about this. Michael Bolton uses to ask me here: “Problem or not a problem?” so that I can decide, what to do next. Inform the next test executed about what to do. After that we take the next reasonable action based on the information we just recently found out about our product. To make the terminology more cohesive here, I propose to coin explored to mean Discovery – Decide – Act.
So, to wrap it up, just like we have Practices, Principles and Values in Agile, we learn using a Shu – Ha – Ri fashion (thank you Declan Whelan for saving the Agile Testing Days for me by mentioning it), we can define “Done” in this same manner:
- Done is Implemented using TDD, Tested via ATDD and Explored using Exploratory Testing
- Implemented using TDD is Red – Green – Refactor
- Tested via ATDD is Discuss – Develop – Deliver
- Explored using Exploratory Testing is Discover – Decide – Act
Responding to Change
During my stay in the US during our vacations this year I was able to collect some notes and reflect on some stuff in the real world and compare it with software development occassionally. Today I decided to do a write up on the “Responding to Change” value of the Agile Manifesto.
While finishing the book The Pragmatic Programmer I got confronted with some concepts that I also noticed in the real world. Early on in the Design Patterns movement I learned to decouple my code as far as possible to allow change to happen. Craig Larman and Robert Martin early on got me into this thought process.
Being a European there were quite a bunch of things different in the US as here at home. Here is a list of things I noticed and I was wondering how hard it would be to change them in our software system. Luckily most of the things I wasn’t able to find at all, whereas most major variation points like currencies or tax systems were also thought on. How does your software respond to change it to the US system? What about selling your software to a European customer? For the testers and checkers among you, would you test that your software supports these? Do you test your software supports these? Does your software support them? Here’s the list, make the test, build up your mind and maybe let me participate in your findings.
Currencies There are a bunch of currencies I was confronted with. Euros of course, Deutsche Mark in the past (does anyone know what a “Groschen” is?), US Dollar, Pennies, Dimes, Quarters, Cents (does your software support the ¢ sign?), Disney Dollars (you can actually pay with it in Walt Disney World ressorts or take them as a gift for your mates at home), …
Tax Maps In the US every single state has a different tax model, even every county can have it’s own. In Germany there are different taxes applied usually, the lower one for food, the higher one for the rest. In Brasil there are 27 states each with their own tax model. Tax laws seem to be the most complex stuff.
Distances Meters, millimeters, centimeters, feet, inches, miles, kilometers, bavarian ells, english ells.
Area sizes Square feet vs. square meters.
Volume Litre, cubicmeters, Gallons to name just some.
Temperatur How many degress Celsius is one degree Fahrenheit? Is 90 degrees Fahrenheit hotter than 30 degree Celsius? What about Kelvin?
Fuel prices How much is 2.59 USD per Gallon in Euros per litre?
Consumption Is a fuel consumption of 28 Miles per gallon the same as 5 litres per 100 kilometers?
Voltages 110V vs. 220V vs. 400V, AC vc. DC.
What did I forget? What hard to change facts do you have to deal with?
People who influenced me
Over the course of creating the Ethics of Software Craftsmanship there was a statement included which tempted me to this blog entry for quite a while now. Here it is:
We can point to the people who influenced us and who we influenced.
At moment there are quite a bunch of craftspersons which influenced me. At the time I’m writing this I am working for three and a half years now in the Software business. Having finished university four years ago, I have gained a lot of experience from some great colleagues, which I never personally met, but which influenced me quite a lot. Today I decided to give you a list of these persons who might not know about their influence on me. I will divide the people into categories: Testing, Developing and Project Management. Personally I might also add Leadership in general, but due to my little experience in this field, I will leave this category out.
Continue reading People who influenced me