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.
One of the main benefits of Acceptance Test Driven Development is that you have your customer involved and can share executable specifications written in human language with all team members including the customer. That’s a major point in favor of ATDD.
Still these creations are just written words. Yes, you can run them against the application once you have built it and it will you that everything is ok. Which is another main benefit. People tend to need some kind of visual to fully feel comfortable with abstract things. Some use wireframes to describe the user interface and then do a walk-through on paper using these drawings. That works but only if the application has a regular user interface where a human user can type and click on UI widgets.
A good while back software developers came up with the idea of a walking skeleton. This has been described in the Crystal Clear book by Alistair Cockburn and in a blog post. Alistair says he found this pattern or strategy around 1994 so it is really not a new idea – but as I find a very good one.
Not only when doing ATDD but in every situation of software development I would like to receive early and quick feedback (in no particular order) on:
- An end to end scenario of some important business action
- The quality of then development team
- Choices for the initial architecture and tools
- Customer’s reaction to a very early version of the product
An end to end scenario of some important business action
Every software program has a number of flows that either a human user or another system interacting with the program under development will use. I’d like to call that a business action because it is an activity to perform some kind of business with a clear goal in mind. The actual implementation of a single business action undoubtedly has a lot of value and may be just enough to deploy the application to production and start using it for real.
When doing ATDD I like to use Cucumber to run scenarios written in Given/When/Then form. After I have identified a valuable business action which appears to be simple enough to be a good candidate for a walking skeleton, I will then look at the expected result. Looking at the result is important. After all that’s why the application is being developed in the first place. So once I know what the outcome should be I write a Cucumber “Then” step.
With the expected result in mind I then figure out what is needed in order to produce said result. This will lead to maybe a number of “When” steps, a few preconditions as “Given” steps and likely I will learn that I need to describe the whole business action in multiple Cucumber scenarios.
Important is to develop these scenarios in collaboration with the customer.
The quality of the development team
Throughout the project the quality of the development team will have a strong impact on the ability to deliver well written software in a reasonable timeframe. The sooner it is known how good the team is, the less disruptive it will be to make changes.
The only way to find out about the actual quality of the team is to do some real work with a clearly defined goal. Building a walking skeleton as an implementation of the business action expressed in Cucumber scenarios is that goal.
Choices for the initial architecture and tools
Whatever my choices are for the (initial) architecture for the application it is a fact that I will never know whether these choices are good or bad until I actually write the code. The goal of producing a walking skeleton puts all my assumptions and decisions to a test. The sooner I find out that I made bad choices the less disruptive it will be to correct them.
I may also find that my choices are ok but I’ve gone overboard with the architecture and thought about implementing a lot of things that I don’t need (a violation of YAGNI – You Ain’t Gonna Need It). Again by putting it to a test I have an early opportunity to find something simpler (simpler – not less capable) that requires less effort.
Speaking about effort… Sometimes tools can be a problem too. Tools may be libraries, frameworks or the programs used to write, compile, package and deploy the code. Trying to produce a walking skeleton in short timeframe and bring it in front of the eyes of the customer will quickly show whether the tools are supportive or hindering the team’s progress.
Customer’s reaction to a very early version of the product
Finally once I have achieved my goal of producing the walking skeleton and my customer can use it for the first time we all will know whether we are on the right track or need to make major changes to our initial assumptions.
Not every customer is the same. Some customers are more willing to collaborate than others. A good opportunity to get an indication of the customer’s willingness to work with the team is by simply watching their reaction to a bare-bones walking skeleton. Do they recognize the business action that was described in the Cucumber scenarios? Can they see the value of the achievement for the project? Are they forthcoming with details to now add flesh the skeleton or are they disappointed?
The sooner I know how the customer really “ticks”, the sooner I can either try to educate and help the customer to better collaborate with the team or – for example as a vendor – decide to abandon the project before getting too deep into an unhealthy relationship.
As this is getting fairly long the next piece will talk about how to actually create a walking skeleton together with Cucumber scenarios.
Doing some reading I came across the phrase “Not everything that counts can be counted” which then led me to a Quote Investigator article where I learned about the person who said this. Here is the original quote:
It would be nice if all of the data which sociologists require could be enumerated because then we could run them through IBM machines and draw charts as the economists do. However, not everything that can be counted counts, and not everything that counts can be counted.
The person who said it is William Bruce Cameron, a sociologist.
I really do like this quote and I should share it with teams that are being asked to quantify the benefits of talented software developers, high quality of code and all the other important things that usually cannot be expressed in numbers. Their absence is visible but only to those who have seen the good things that happen when they are present.
Here is an observation that is making me more and more angry. Why is it that so many people in larger organizations who work somewhere in software development expect that everything needs to be a step by step process?
I see members of development teams talk for hours over how they want to move cards on a kanban like board. Which role does what part of the work. When do pairs have to switch. It is almost as they need to create a huge bureaucracy that governs every little detail of the activities in their open space team room.
So why do they do that? They are in an environment that is physically open and allows for every easy collaboration. Isn’t it normal for humans to simply start talking to each other and figure out things together in any order? At least children would certainly do it without much thought.
Do they act the same in their private life? Have they been raised by parents who used step by step processes during their upbringing? I very much doubt that. Life is usually full of uncertainties and surprises.
Maybe it is that they think that software development is engineering and therefore everything needs to be exact, controlled, verified, etc.?
Maybe they think that following a prescriptive process makes them look more professional?
Maybe it is that they fear to make mistakes and be punished for making them. So they like a prescriptive process that allows them to show clearly they have just following the rules and hence should not be punished. The process as a scapegoat?
Whatever it is Software Development is definitely not the same thing as engineering. At least not as non engineers imagine how engineering actually works. I am not an engineer but I pretty much expect that good engineers do know how to deal with uncertainty. Why would they build prototypes, mockups, run simulations and all that before building the real thing?
Maybe it is simply lack of experience and a general immaturity of the people involved that leads to this desperate holding on to prescriptive processes. It is easier to follow step y step instructions than to understand abstract objectives and adjust while doing something.
On Twitter someone linked to a scientific paper titled “About the Return on Investment of Test-Driven Development“. The abstract reads:
Test-driven development is one of the central techniques of Extreme Programming. However, the impact of test-driven development on the business value of a project has not been studied so far. We present an economic model for the return on investment when using test-driven development instead of the conventional development process. Two factors contribute to the return on investment of test-driven development: the productivity difference between test-driven development, and the conventional process and the ability of test-driven development to deliver higher quality code. Furthermore, we can identify when TDD breaks even with conventional development.
I would like to call this a missed opportunity.
The authors set out to compare the economic impact of TDD with traditional development that is not based on a test-first approach and try to present an economic model for the return on investment of TDD.
The paper then is filled with many impressive calculations and graphs but basically only talks about the cost of doing TDD vs not doing it and which approach is faster. That is not really helpful and in my understanding just demonstrates a lack of understanding why programmers use TDD in the first place.
Benefits are analyzed by looking at what they call the defect-removal-efficiency as that were the goal of practicing TDD.
Here is a quote of their conclusions:
We propose an economic model for the return on investment of test-driven development. Our analysis of the break-even leads, all other parameters are kept constant, to the following conclusions:
- The return on investment of TDD depends to a large extend on the slower development of TDD and the higher quality code of TDD.
- Other factors like the effort for fixing a faulty line of code, or, the productivity of a developer using the conventional development process, have only minor impact on the return on investment of TDD.
- The calculation of the return on investment is independent of the project size, the number of developers, and the developer salary.
Our model assumes an experienced TDD team. The additional cost for training which is necessary when first introducing TDD is ignored so far.
Finally, our model strengthens the need for actual empirical figures (or ranges) for the quality advantage and the loss of productivity of TDD, in order to get a comprehensive evaluation of the cost and benefit of TDD.
The benefit of doing TDD is in better and cleaner code that is testable. It is a misconception that simply by doing TDD a team can create code faster. Speed is not the concern here.
Code that is developed without doing TDD is more coupled and changing it is much more risky simply because one never can know what breaks until someone actually tries to test the application. Then the next question is how do you test all the code, if the only means of testing is using the application? It is obvious that you cannot test the whole application right after you made a change. So you will test after a while and by then many changes have been done and it becomes hard to find out which one broke it. That is a long feedback loop and inherently dangerous.
Managers know that risk is bad and they usually try to mitigate it. So if changing old code that has no tests is risky business, they may play it save and not ask programmers to change it at all. That then either leads to inflexibility, loss market opportunities or the big rewrite project many years later. If the application is somehow important, not doing TDD is by factors more expensive than any expense incurred while doing it. Not doing TDD may lead to loosing the software asset completely or to lost business. Both losses are usually higher than the cost of even a few thousand hours of programming.