For the second day of Agile Conference 2007 I hit two sessions:
- Agile Developer Practices for Dynamic Languages (“Paul King”:www.asert.com)
- The Crystal Methods (“Alistair Cockburn”:http://alistair.cockburn.us/)
Agile Developer Practices for Dynamic Languages
This first session was alright. The presentation revolves around the presenter being well grounded in Java and its related technologies, and recently he has been moving towards dynamic languages. As he and his team are moving towards dynamic languages (he prefers “Groovy”:http://groovy.codehaus.org/ and his non-present co-presenter preferred “Ruby”:http://www.ruby-lang.org) they are realizing that a lot of design patterns, techniques and requirements of statically typed languages aren’t required, or are implemented completely different in dynamic languages.
The talk really focuses on showing people who understand things in java, but not in dynamic languages, that in fact you can do the same things (or in some cases you don’t need to do it at all) in a different way. He walked through things like:
- dynamic builders (think “Markaby”:http://redhanded.hobix.com/inspect/markabyForRails.html or “Haml”:http://haml.hamptoncatlin.com/ in ruby) vs. using builder objects in java
- you don’t really need factories like you do in java
- delegation is much simpler then it is in java
- DSLs are easier to write then in is in java
- brief examples of “meta-programming” and that it sucks to do in java
Three people in the session couldn’t get over the fact that with dynamic languages you lose the ability to have auto-completion in your editors with the same level of granularity that you get with Java code and editors like IntelliJ or Eclipse. If their ability to productively program comes down to auto-completion or they think that auto-completion will hinder their ability to effectively solve problems I think there are bigger problems on there team.
The Crystal Methods
“Alistair Cockburn”:http://alistair.cockburn.us/is a great speaker. He started out by focusing on how he believes people learn. According to Alistair people learn in three states: learn (shu), collect (ha), and invent/blend (ri). These stages directly correlate to the level of understanding and experience someone has in a particular area.
People start in the “shu” stage and learn with a clear set of instructions and/or rules. Next people move to the “ha” stage where they are able to apply the rules and they are able to understand that the rules aren’t necessarily giving them the best results. Here they start to experiment with edge/exception cases and they apply different rules. In the “ri” stage the person has moved beyond the instructions/rules.
Moving on from how people learn, Alistair presents Crystal as a collection of methodologies, and he believes that different methodologies are better suited for different types of contexts and number of people. Hence there are Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red.
He points out that Crystal methodologies won’t tell you how-to do something, they will merely tell you the properties that you need to have to be successful, and as a team he expects you to find the best ways to get there, although he does assert that certain key techniques (like Reflection, high visibility, etc) are key to implement Crystal methods.
Alistair’s background for coming up with Crystal Clear started back in the early 90s when he started traveling worldwide to to talk to different team about their projects. Through his years of experience he concludes that Crystal is made up of the good things that were common among all of them.
Alistair also believes that methodologies can be classified by a given genetic code. Here is the code for Crystal:
- Design priorities
- Project priorities
- Design principles
- Key techniques
He also focuses on the seven properties of a successful project:
- Frequent delivery
- Reflective improvement
- Close communication
- Personal Safety
- Easy access to expert users
- Technical Environment ** automated unit tests ** automated acceptance tests ** frequent commits and system integration
Crystal itself is based on the first three of these properties.
In the past I had read the Crystal Clear book and I have even implemented many of the properties and techniques in it so the session wasn’t completely new material, but I feel I was able to take away more from the session from having prior knowledge then if I were to come in with a blank slate.
blog comments powered by Disqus