Last week I have attended the JAX conference in London. Here is a couple of highlights that attracted my attention enough to write them down.
Product Backlog
Roman Pichler about the Product Backlog:
Low-priority backlog entries should be much less detailed than those on top.
When (and if) their time comes, they will be probably split into smaller stories. This also shows that the backlog is something designed to be often changed (and reviewed!).
Why do you need to allocate time for gathering requirements/design/architecture work every iteration?
Think about the Waterfall approach and all the work done in the initial project phase, before coding. When following Scrum methodology this work still remains. The only difference is that it is now scattered among the iterations.
Guess the number
Jason Gorman came up with a great exercise during his Keynote. 2 teams were trying to guess the 4-digit number, taking turns.
? ? ? ?
One team was made to guess the whole number up front, while another one were free to guess it digit by digit.
Now, Dear Reader, guess who was able to figure out the number faster and which team represents the Waterfall and which one is Scrum 😉
Jason also pointed out that when building a software solution “how fast we learn is actually more important than how fast we deliver”.
Measuring effects of TDD
In the introduction to his talk, Keith Braithwaite showed a correlation of Cyclomatic Complexity values against the probability of faults being found, which I find really useful to convince myself to think twice before adding another “if” into code. And, yeah, at some point the probability reaches 100% 😉
Keith’s analysis of Cyclomatic Complexity distribution in various open-source projects proved that in the tested code one can observe higher preference for less complex methods, though there still remain parts of code of high complexity.
What is more, a nicely TD-Designed project’s code needs somehow express the same behaviour as the codebase with lots of “if” statements. How is this richness achieved? Well, maybe we trade off here more interactions (and greater coupling!) for less “ifs”.
We are all lazy
Last but not least, I found one explanation on why writing tests leads to shorter methods really interesting. Long methods may not be hard to write, but they make testing difficult. Big tests are hard to write indeed. So, when it comes to writing (long) test cases, your laziness forces you to… refactor for smaller methods, cause this will simplify testing!
The best presentation I have attended on the second day was Thinking Distributed to Improve Agility by Jamie Allsop, but… that is another story.
pawel.wrzesz.cz 