A few months ago I wrote a review of the Who is Agile set of interviews compiled by Yves Hanoulle. Time has passed now as Yves has been back in touch and as the book has evolved I'm writing this follow up.
I think that any community has its fair share of navel gazing and it seems that the agile community suffers especially from this. Too often the Agile manifesto's signatories are put up on pedestals and listened to without question. Too often are practicioners sat around telling each other "didn't we do well". When I first came to read "Who is agile" these were the biases that I was laden with and consequently I had some reservations of the underlying purpose of this book and the value that it would bring to those not in the circles of the contributers. I also think that this behaviour is why there are such strong opinions still over agile and I think that some of the criticism is valid.
(It's probably worth reflecting on at this point that this cynicism may be saying more about me that it is about any community)
So inspite of the review Yves has continued on with adding to the book and I've continued to read it.
After grumpily dismissing the format I think I've now think I've worked out at least one way to read it. This book is not about names, nor agile. It's a book about people. If you forget the names and bio bits and just read the questions and answers you get a fantastic insight into how these people tick. Some of the best interviews are where the interviewees talk less about software development and more about the other stuff that defines them. I believe in that to be a good software developer you need to have experience in other 'stuff'. Some stories are very personal too and it's fascinating the influence that some of those incidents have on those people.
I normally read the book on the kindle but that is only half the fun. As the book has become to big to email to the kindle (via gmail at least its > 20mb) I've found I read it less but when I do there's added value. Each interview is scattered with lots of hyperlinks, some go to just some strange places, others infomative distractions, or just plain definitons. You could get lost for hours just reading through some of the links and if you are stuck for ideas for books each interview will suggest a new one. This is really Who is agile's strengh. It's a cornucopia of information! (or a yak-shaving utopia).
The other criticism I had originally was that the book had a narrow geographical focus. Yves has done well by getting a more diverse (geographically) set of people. Yes the book still is predominatly a euro-us set of interviews but there's more from futher a fields. This feels more like a truly diverse publication.
I'm impressed with how the book has progressed. For its current minimum price ($9.49) there is so much in there. Don't be put off it you don't know (or like) agile. This is not an agile book, it's a book full of stories about software people.
Wednesday, July 25, 2012
Monday, July 23, 2012
The evils of auto properties & object initializers in c#
I've been thinking a little bit about object orientation recently. It seems that OO was the poster child of the 1990s and has been the leading paradigm through the first decade of the new millenium. The thought behind this was that object reuse would solve all our problems but in reality they didn't. Even with languages gaining objects, C evolves to C++, and being built with objects from the ground up such as Java and C# people still seem to just not get it.
Back in OO school I learnt that objects should be polymorphic, inheritable and encapsulate discrete bits of behaviour. In OO college I learnt that we should strive for low coupling between our classes and high cohesion. In OO university I learnt about the SOLID principles and that I should favour composition over inheritance. It's been a long journey and I'm still on it but all over I'm still seeing non OO code in .NET all over the place. Is OO too hard for people? Or is just a broken paradigm?
Well my friends, OO is hard but I don't think the C# language designers have helped. The two worst features for Object Orientation in c# are auto properties and object initializer syntax. "What?" I hear you say, "Auto Properties? But they're so useful! (and cute). Object initializers they save so much time!"
They are evil.
More and more I'm beginning to see classes like this:
and initialisation like this:
People are abandoning the general principles of object orientation. We are exposing the internals of our objects with gay abandon. This is a dark route that inevitably leads to pain. Every time you use a vanilla auto property you are introducing an opportuntity for coupling, which reduces the modularity and resue of your code. Your classes becomes mutable so lose all the goodness that immutability brings. By allowing 'Children' to be initialised in this way you break the Principle of Least Knowledge and couple your class even further. It's no wonder that we can't do OO if we take short cuts like this. Now of course there are reasons for using initializers, simple DTOs and anonymous classes spring to mind but don't be fooled by this syntactic sugar, it will rot your teeth!
Back in OO school I learnt that objects should be polymorphic, inheritable and encapsulate discrete bits of behaviour. In OO college I learnt that we should strive for low coupling between our classes and high cohesion. In OO university I learnt about the SOLID principles and that I should favour composition over inheritance. It's been a long journey and I'm still on it but all over I'm still seeing non OO code in .NET all over the place. Is OO too hard for people? Or is just a broken paradigm?
Well my friends, OO is hard but I don't think the C# language designers have helped. The two worst features for Object Orientation in c# are auto properties and object initializer syntax. "What?" I hear you say, "Auto Properties? But they're so useful! (and cute). Object initializers they save so much time!"
They are evil.
More and more I'm beginning to see classes like this:
and initialisation like this:
People are abandoning the general principles of object orientation. We are exposing the internals of our objects with gay abandon. This is a dark route that inevitably leads to pain. Every time you use a vanilla auto property you are introducing an opportuntity for coupling, which reduces the modularity and resue of your code. Your classes becomes mutable so lose all the goodness that immutability brings. By allowing 'Children' to be initialised in this way you break the Principle of Least Knowledge and couple your class even further. It's no wonder that we can't do OO if we take short cuts like this. Now of course there are reasons for using initializers, simple DTOs and anonymous classes spring to mind but don't be fooled by this syntactic sugar, it will rot your teeth!
Subscribe to:
Posts (Atom)