Archive for May 2011
This is the second part of a mini-series about the use of a walking skeleton in Acceptance Test Driven Development. In this installment I want to show how a team can get started with the walking skeleton and what to expect.
The first order of business is to write at least one Cucumber scenario that describes one business action from end to end. It could be something like this or multiple scenarios depending on the application the team wants to build:
Scenario: Given I am a visitor to the pet clinic website And my pet "Charley" needs rabies shots When I make an appointment Then I receive a confirmation email And the appointment is known to the office of the pet clinic
With that the team can get started. The primary objective is to make this scenario pass and it does not matter how pretty the application will look nor should we think too much about any details just yet.
Deliver something useful in a couple of days
It is important to build the walking skeleton as fast as possible. It doesn’t have to be pretty, but it needs to pass the test expressed in the Cucumber scenario(s). The faster the walking skeleton is delivered and presented to the customer, the sooner there is feedback and the customer sees some working software for the first time. That enables the customer to check his initial assumptions and may lead to a few dramatic changes. At this early stage any change, regardless how big it might be, is cheap. So again: the sooner the whole team can look at and play with actual software, the better.
The rubber hits the road
As I was saying in the first post of this mini-series the walking skeleton not only will deliver something to the customer to obtain his feedback but also will put the team to a test. The rubber hits the road and you will know what you can do and where you have deficiencies and need to learn or fix things.
No place to hide
Discovering early on where your problems are is healthy and helpful. But then I also made the experience that not everyone likes to be so exposed. For example there might be a programmer on the team who does not possess the skills required to actually deliver something lightweight in a couple of days. While building a walking skeleton there is no place to hide. If that happens an assessment should be done to figure out whether the skills of such a team member can be improved within a short timeframe, the project can afford to have someone learning or not, whether there is budget to bring in a coach, etc. If that is not an option, then at least there is a chance to remove the person from the team and find a replacement so that the remaining team can deliver.
Related: In his blog post Avoiding Iteration Zero George Dinwiddie writes about the same thing. He does not use the term walking skeleton but instead he suggest to get started with one obvious thing that is the main purpose of system being built but the intent is exactly the same.
We have finally matured. What we now produce are Reflective Improvement Frameworks, not methodologies (though we often still say that out of habit). Crystal, Scrum, Kapital-K Kanban are examples. Each contains a few rules, not enough to run a project, but enough for people to improve their situation better than merely inspecting and adapting. Old-style Big-M Methodologies are gone. And that’s good.
There is nothing to add. Follow the link and read the full blog post.
Crafts such as carpentry and masonry – just to name two – exist since many thousands of years. We call them traditional crafts and most practitioners of these crafts keep up the traditions for a good reason.
For example German carpenters adhere to very strict rules that govern training of new craftsman. Not only that. Many of them are proud craftsman and prefer to work in traditional clothing. One item of that traditional workwear is called Ehrbarkeit which translates to respectability. It is similar to a tie but instead of going around the neck is just a narrow strip of fabric. Depending on the guild the carpenter belongs to the color of the Ehrbarkeit varies.
The basic idea behind this symbol is to tell a potential customer that the carpenter is a respected and responsible craftsman who performs work that is governed by the standards (quality standards that is!) set by his guild. He is a respected craftsman because he earned that respect through achievements and has passed exams to be accepted as a member of the guild. It is expected that he will protect his reputation by not delivering bad quality or bad value.
In software development we don’t have a history of a few thousand years to draw from. The computer was invented almost “yesterday” when in Konrad Zuse built the Z1 between 1935 and 1938. The first high-level programming language Plankalkül was created by Konrad Zuse between 1943 and 1945. So our craft is extremely young and in its very short history many attempts have been made to either associate it with math or engineering or simply determine it were a field within these disciplines.
Only in the last 10 years people have started to think about software development as a craft and the software craftsmanship movement appeared.
My understanding of being a software craftsman is that I have to be honest, open and truthful. I need to deliver value to my customer and make decisions based on my experience. I need to know how to use the tools of my craft effectively and with efficiency. And I need to protect my reputation by not engaging in practices of which I know that they are not effective or harmful to the health of the project or may lead to problems for my customer in the near future.
Here is an example. If my customer expects me not to practice Test-Driven Development in order to get results faster and my long-term experience is that by doing TDD I can create code of higher quality that is more maintainable and more reliable than code without tests, then I should never accept any direction not to do TDD. If I did, I certainly were about to loose my reputation or were committing some sort of treason to myself.
As a craftsman I should know why I do things in a certain way. I should be able to explain and justify my decisions and, of course, deliver good results to the benefit of my customer.
The more software craftsmen work in all the companies that develop software, the more the craft improves. The more craftsmen are out there, the better customers learn what high quality software looks like and what it takes to create it. As a consequence the easier it will be for good craftsmen to find customers and the harder it will be for all the charlatans who do a lot of damage to our customers.