Reblog

This week’s highlights

Several podcasts this week and good articles. Enjoy!

Podcast #41 - Blog - Stack Overflow… Ha! Too politically correct (you need to listen stackoverflow 38 to understand this). Or maybe this is how things should be. I had the impression that Jeff and Joel agreed that the wrong thing was to be so harsh and offensive about quality code and TDD but they stay on their respective positions.

Uncle Bob - Oredev 2008 - Clean Code III: Functions… The Clean Code book by Bob Martin is still sitting on the book shelf. I’d like to find the level of attention ant time to read it and that day is coming closer. In the meanwhile I managed to have an impression about what’s inside the book through this presentation at Øredev. I know you can get just an impression considering the many skipped slides. This is the kind of book you want to read if you care about the details of clean everyday programming with an eye on principles and the high-level design. There are interesting challenges in the presentation like trying to understand messy code in 3 minutes. Listening to Bob talking is never boring, give it shot.

Pat Maddox - OO Minifesto… I like Pat’s application of the SOLID principles on top of a simple example. This is the kind of inquisitive behavior that the SOLID principles should guide you through. But, I think that the “action” that the principle is calling for should be driven by a business requirement. What I do is I take note of the possible smell/refactoring but I don’t apply it right away. I wait until another business requirement call for the refactoring and at that point I reevaluate the need for generalization/refactoring. If that still holds true, I apply the principle. In my opinion, this is YAGNI and prevent premature generalization.

Jay Fields’ Thoughts: Questions To Ask an Interviewer… Here’s a starting point for that tricky question you are asked usually at the end of an interview. Do you have any questions for us? I remember that my questions are often related to the process and the organization. I try to be inquisitive about buzzwords used by the interviewer and I always ask something like: “if you decide I’m the right person for you, what kind of role do you see for myself in your company?” I try to understand if they are hiring with a long term plan in mind or just because they have some urgent need at the moment.

99 Cent iPhone Apps Not Significantly More Popular… Again on the topic of “fairness” at the iTunes store. There seem to be an uniform distribution of applications on price bands and popularity with no interesting skew. But as Jack was saying at the MobileOrchard podcast the other day, there is no way to correlate quality. What is quality for an iPhone app? Is quality of support, quantity of bugs, quantity of releases before the product disappear, speed in fixing issues and in general reliability. I understand it’s difficult to track these important metrics but the “popularity” only is not a good enough indicator over time. For this reason, very good application drop out from the top 100 too quickly.

Rob Conery limps and learns about Domain Driven Design Hanselminutes… I tried several times to understand what DDD is. At the end I always have this feeling of patterns of enterprise architectures plus a process where the design is upfront like the old RUP school. Clearly my effort is not enough but at least I know that I’m not alone struggling with the definition. In this podcast, Rob and Scott decided they are not in the position to give us a definition but nevertheless they are telling us where to start to understand DDD principles. I appreciated the effort and the good conversation. Also notice the difference: if this was StackOverflow podcast I’m pretty sure that instead of declaring their ignorance, Joel and Jeff would probably bash DDD as an useless acronym since their business does great already without it. Same happened to SOLID.

Cocoacast Talk Episode 21- Interview with Jack Ivers… Jack is for sure a great evangelist of GuitarToolkit and my company products in general. I’m not saying this just because he’s my boss :) He received some tricky questions triggered from the company name: how can you think that a company named AgilePartners is not using state of the art Agile processes? Well we aren’t. There are experimenters as usual, using practices here and there. The truth is that AgilePartners works great for the presence of bright programmers and managers who are self-disciplined and the entire company seems to be based on self-discipline as a result. But another truth is that we’ll never know if we are even capable of more until the formal application of a software process (and maybe the consequent refusal of the process) is in place. In the meanwhile, I’m glad to see that typical agile values (as from the manifesto) are already part of the company.