Agile Conference 2009 - Day One
It's been 5 years since I attended the granddaddy of Agile conferences and I have to say that the first day was damn good. My notes my be a little rough, so I apologize in advance, but if I don't type and post them on the day I pretty much never will.
Workflow is Orthogonal to Schedule -- Mary Poppendieck
Mary started out with an example of on time development from 1929: The Empire State Building.
In September of 1929 they started cleaning the constructions site of previous buildings and by May 1st of 1931 the building was finished and open to the public. It was exactly on time and 18% under budget.
Cash flow was king: Every day of construction was another day before they could start getting their money back.
How did they do it? They focused on flow. They thought of the project as "A marching band going through the building and out the top."
Key success factors:
Mary used this as a shining example of Lean development in the pre-computer era. So how do you run a software project with the highest degree of efficiency possible?
At this point she compared Kanban to Iterations. This article describes Kanbab better than I could do it justice: http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
Schedules (are way different from flow)
1. If you have a level work flow you have both predictability and control without a schedule
2 Schedules based on experience are reliable
3. Schedules summed up from task breakdown are not.
- without experience, task break-down/sum up schedules are a hypothesis
- without slack, task breakdown/sum up schedules are deterministic and do not allow for normal variation
- attempts to remove normal variation from a system cause oscillation
Asking for feedback means you'll get it. You can only commit to 50-70% of what you want because you will get feedback that takes over the rest of the time.
Small batch size means you can get 80-90% utilization -- an iron law of math. Utilization above this range causes thrashing and wastes lots more time than it gives you.
Optimize Throughput, not utilization
She covered a lot of interesting stuff in her talk and I feel like I've not really captured the flow and force of her arguments. Mary is one of the best Agile speakers around and I recommend taking any opportunity to see her talk.
What Do Agile Coaches Do? -- Liz Sedley and Rachel Davies
This was a tutorial were the audience broke into groups and discussed Agile coaching. The presenters posited that there are 3 types of coaching:
We looked at some common problems that Agile coaches face and discussed solutions. I thought the conversations I had were pretty interesting but I would have liked to hear more from Liz Sedley and Rachel Davies about there experiences in Agile coaching as they had just written a book on the subject.
Integration Tests are a Scam -- J.B. Rainsberger
This was a pretty awesome talk and I totally owe my attendance to Colin Harris, as he recommended a blog post to me about just this topic by just this author.
J.B. defines integrations tests as any tests that test more than one class.
Why is this bad? Well he spent 90 minutes making a very solid case, but let me try to sum up:
First he started off by saying that he's talking about developer tests and not customer tests. In other words, he cares about tests you run before you check in not huge regression suites used by Q.A.
1. Integration tests are slow. Slow tests will eventually become ignored tests.
2. Testing a group of, say, 3 interacting objects creates a ridiculous amount of tests you need to write. If there are 5 paths through the main object under test, but the methods it uses in another object have 3 and 10 paths respectively then you should write 3 X 5 X 10 = 150 tests to exhaustively try out all the paths. However, if you test each object in isolation then you need to write 3 + 5 + 10 = 18 tests to get the same coverage of paths. You are far more likely to write 18 tests, then 150.
The way J.B. does this is to create interfaces for all his objects that have complex behavior (He likes Domain Driven Design so he tends to refer to these objects as 'Services') and then use 'Doubles' (mocks and stubs) to eliminate the need to use the real objects. Now when you use doubles, you need to make sure that the thing you're mocking on one end really does return what you think it does on the other.
When I asked him about having setups with lots and lots of mocks he claimed that if you're having trouble mocking things in your tests you probably have problems with your models. Sigh. He's probably right. For instance, if you need to have a mock that returns a mock which returns a mock you probably have an object that is breaking your layered design.
Of course when I test in Rails I have to do this all the time. Part of the reason is that good design is way hard and I'm still learning. But the other is that Rails has ActiveRecord which is an entity that is responsible for it's own persistence and that is something that J.B. and a lot of people I respect look down upon.
Rainsberger gave me a lot of things to think about which is pretty much the highest praise I can give a session.
Workflow is Orthogonal to Schedule -- Mary Poppendieck
Mary started out with an example of on time development from 1929: The Empire State Building.
In September of 1929 they started cleaning the constructions site of previous buildings and by May 1st of 1931 the building was finished and open to the public. It was exactly on time and 18% under budget.
Cash flow was king: Every day of construction was another day before they could start getting their money back.
How did they do it? They focused on flow. They thought of the project as "A marching band going through the building and out the top."
Key success factors:
- The owner, architect, and builder got along well and worked as a team.
- They had a deeply experienced building team.
- There was a lot of focus placed on the key constraint: Material Flow. 500 trucks a day but only arrived with materials for the building, but they only had a few days of storage on site so everything that arrived had to go up and onto the building.
- Decoupled the work: The systems (windows, floors interiors) were designed to be independent
- Cash flow thinking: Every day of delay coat $10,00 ($120,000 in today's dollars)
- The schedule was not derived from the design. The design was put in place to meet the constraints of the schedule.
Mary used this as a shining example of Lean development in the pre-computer era. So how do you run a software project with the highest degree of efficiency possible?
- Establish high level system goals (what do we really need).
- Involve those who understand the details early in the process.
- Use teamwork based on trust. Contract thinking increases costs 30-50%.
- Reduce complexity wise wise decoupling
- Understand and manage the constraint
- Features can be big but dev stories must be small (1-3 days at most)
At this point she compared Kanban to Iterations. This article describes Kanbab better than I could do it justice: http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html
Schedules (are way different from flow)
1. If you have a level work flow you have both predictability and control without a schedule
2 Schedules based on experience are reliable
3. Schedules summed up from task breakdown are not.
- without experience, task break-down/sum up schedules are a hypothesis
- without slack, task breakdown/sum up schedules are deterministic and do not allow for normal variation
- attempts to remove normal variation from a system cause oscillation
Asking for feedback means you'll get it. You can only commit to 50-70% of what you want because you will get feedback that takes over the rest of the time.
Small batch size means you can get 80-90% utilization -- an iron law of math. Utilization above this range causes thrashing and wastes lots more time than it gives you.
Optimize Throughput, not utilization
She covered a lot of interesting stuff in her talk and I feel like I've not really captured the flow and force of her arguments. Mary is one of the best Agile speakers around and I recommend taking any opportunity to see her talk.
What Do Agile Coaches Do? -- Liz Sedley and Rachel Davies
This was a tutorial were the audience broke into groups and discussed Agile coaching. The presenters posited that there are 3 types of coaching:
- Consultative - Trying to change process
- Motivational - Encouragement
- Education - Helping understanding
We looked at some common problems that Agile coaches face and discussed solutions. I thought the conversations I had were pretty interesting but I would have liked to hear more from Liz Sedley and Rachel Davies about there experiences in Agile coaching as they had just written a book on the subject.
Integration Tests are a Scam -- J.B. Rainsberger
This was a pretty awesome talk and I totally owe my attendance to Colin Harris, as he recommended a blog post to me about just this topic by just this author.
J.B. defines integrations tests as any tests that test more than one class.
Why is this bad? Well he spent 90 minutes making a very solid case, but let me try to sum up:
First he started off by saying that he's talking about developer tests and not customer tests. In other words, he cares about tests you run before you check in not huge regression suites used by Q.A.
1. Integration tests are slow. Slow tests will eventually become ignored tests.
2. Testing a group of, say, 3 interacting objects creates a ridiculous amount of tests you need to write. If there are 5 paths through the main object under test, but the methods it uses in another object have 3 and 10 paths respectively then you should write 3 X 5 X 10 = 150 tests to exhaustively try out all the paths. However, if you test each object in isolation then you need to write 3 + 5 + 10 = 18 tests to get the same coverage of paths. You are far more likely to write 18 tests, then 150.
The way J.B. does this is to create interfaces for all his objects that have complex behavior (He likes Domain Driven Design so he tends to refer to these objects as 'Services') and then use 'Doubles' (mocks and stubs) to eliminate the need to use the real objects. Now when you use doubles, you need to make sure that the thing you're mocking on one end really does return what you think it does on the other.
When I asked him about having setups with lots and lots of mocks he claimed that if you're having trouble mocking things in your tests you probably have problems with your models. Sigh. He's probably right. For instance, if you need to have a mock that returns a mock which returns a mock you probably have an object that is breaking your layered design.
Of course when I test in Rails I have to do this all the time. Part of the reason is that good design is way hard and I'm still learning. But the other is that Rails has ActiveRecord which is an entity that is responsible for it's own persistence and that is something that J.B. and a lot of people I respect look down upon.
Rainsberger gave me a lot of things to think about which is pretty much the highest praise I can give a session.
Comments
With duck typing in Ruby we don't need interfaces to stub/mock ActiveRecord classes in Controller specs. This helps a lot. I find it easy to write isolated specs for Controllers by writing Test Doubles for the pieces I need to simulate (session, ActiveRecord classes, filters, ...)
So I don't look down as much on ActiveRecord for combining the model class with the persistence service, because Ruby doesn't force me to extract interfaces for everything.
I suppose I have an underlying assumption of languages without duck typing when I make some of the assertions I make in my Integration Tests Are A Scam talk and articles. But then, I use those articles and talks to surface my assumptions and improve my arguments.