Today I attended a meeting of the Software Craftsmanship in Israel group with Corey Haines.
Corey gave a talk about agile practices and how to decide which to choose.
The talk went something like this:
Our objective is to reduce the time between doing something and doing the right thing and the time between doing one thing and starting the next one. And thus the goal of every single methodology is to make the feedback loop smaller – at all levels.
The main reason we want to reduce the feedback loop and provide value as soon as possible is that we want to minimize the cost of change. The cost of adding feature decrease over time – the promise of agile/code craftsmanship is that that time would not be exponentially – it would still be fairly easy to add a new feature a year from now.
Usually systems begin simple and beautiful and over time as the features accumulate it becomes more and more complicated. This can be handled by using evolution design/Iterative design which means that you take the time to clean your work after adding a feature instead of rushing to the next task on your to do list.
Early feedback by giving product early. Because it’s much nicer to change a system when its small. Thus reducing the time between doing something and finding out what you should have done.
The second part of the session was about testing and on how to reduce the Dev-QA feedback cycle which is why too long. In essence the objective is to know if the code today works as well as our code yesterday or even if our code work as well as 5 min. ago. Corey has talked a while about testing and automation and how to reduce the time to deployment.
One of the key points I liked was that we shouldn’t discuss whether or not a methodology A is better than methodology B we should discuss the value we’ll receive from using that methodology.
And finally a simple rule: If you choose not to use a practice, you must replace it with another of equal value.
Corey has answered a few questions from the audience about how to evaluate the cost of certain practices, mocking and working with legacy code followed by a short exercise – we had to parse Piet code by hand – namely the following “program”:
I caught two of Typemock’s finest – Gil Z. and Elisha writing a parser using unit tests and what looks to be a new soon to be released tool.
All in all an evening well…
Just a quick reminder
I’ll be presenting at the Agile Practitioners conference next week – so don’t forget to come and say hi. And incase you’ve missed Corey’s session or want to hear more of what he has to say about agile and software development in general – come to the Agile Practitioners conference next week.
Didn’t sign up yet – don’t worry because registration is still open. Just tell them I’ve sent you or better yet use this link.
See you there!