This week’s highlights
Here we go again. I just finished watching all the act_as_conference 2009 talks and the most interesting are already in my notes below and older posts. I’m now going through RubyConf videos and that will take more time. But still, having fun learning so much from the comfort of my chair. Happy weekend.
Agile Corner. Interview with James Shore | CocoaCast… This podcast is a concentrate of good stuff (and Vlad is a great interviewer). Let’s start with distributed agile tips: teams travel a lot, everybody at the phone for call conferences, no main physical board (same handicap). Kanban: especially good for maintenance or established products because there is less need for predictability which is easier with iterations. Last advice for those situation where a strict planning is required: let the team have at least 3/4 iterations first to give more reliable estimates. If you don’t then you get those fixed bid projects where you deliberately under-bid to make profit on change requests later. Only one thing I disagree at the very end: it’s true that static analysis tools tell you what you can easily see in code. But it’s the game that matters: play against your self to see those numbers changing.
Jay Fields’ Thoughts: Thoughts on Developer Testing… A post about testing, full of “from the field” advices. Number one: if it hurts you’re doing it wrong. Jay describes a situation where common test patterns or tools are applied without a conscious decision like a big design up-front. Contextualize is again the keyword. There was a time I did the same: I thought mock-all development was the way to go and I started mocking all collaborators to discover interfaces. Which is of course not bad at all! The problem is if you decide that is the only approach possible for the entire application. Test maintenance is going to eat 100% of your time.
Relevance Blog… I’m glad to read about the details of well known companies like Relevance. I usually learn something original (I recently had good reading also about HashRocket and Pivotal Labs). The open source Fridays for example. Instead of dedicating an average 20% a week to open source projects, at Relevance they decided to concentrate the effort on a single day. This set the customer expectation in a very clear way. Personal retrospectives instead of standard progress reviews. Here you can talk with not just the boss but with the entire team that can give you advices and positively judge you. Third the hacker in residence program (similar to Hashrocket’s rockstars) where you develop with the team for a good 6-12 weeks.
On Being A Journeyman Software Craftsman: Road Thoughts - Practice… Of the many good posts from Corey Haines I chose this one to remember about an important fact he often repeats. For practicing, a software craftsman would start from those skills which fail under the pressure of a release. The different behavior between the comfort of a regular day at work and the stress of an incoming release is the measure of what you still need to practice. The lack of practice is also responsible for the perceived “slowness” that forces the developer to give up on “decorations” when the timeline is approaching.
Context, My Foot! Hot Needle of Inquiry… I’ve got the same impression that Ron Jeffries describes in his post. The need of flexibility that label Kent Beck’s Extreme Programming Explained 2nd ed. was a double edged sword. In name of that flexibility many teams defined themselves “agile” after the exclusion of XP practices not compliant with their “context” without even try them first. Which is of course bad because it’s then easy to blame agile for a failure that is dependent on the same context that prevented the real agile adoption.
Mark Nijhof about Craftsmanship… The content of this post is extremely true. IT industry customers tolerate low quality standard for software but do not tolerate the same for other crafts or industries. Why is that? It could be that IT is very young compared to millenary crafts like building a house and therefore people believes that chronic late releases and lot of bugs are “normal” in software. Is our (developers) responsibility to raise the bar and the customer expectation level. I also believe that the software craftsmanship movement is the answer not only Agile practices.
3 years ago