Groovy vs. Ruby

Both are very compelling and provide with very powerful abstractions...

but...

• I don't really like the syntax in Perl and unfortunately Ruby is living in that space..
• Groovy seems a bit lagging behind in areas like parallel assignment
  
• No good IDE support overall, maybe next year :)

despite that...

• Groovy really shines with its natural Java blending capability
• I love the Grails project, showing what is possible with Spring and Hibernate
  
• Dynamically typed languages are just sweet... write less and no interruptions in your flow
• Groovy just added Annotation support, that is way cool
  

I devoted some nerd-time to learn both last year and I really enjoyed the exposure. I think its important to experiment with different conceptual tools such as programming languages from different paradigms as it expands on the set of potential solutions you can dream up for a particular problem.


So for example...
Say for example how nice it would to be able to do something like this in Java:

Map stuff = {"locale" : "en", "theme" : "basic" }

...but of course we cant so we have to resort to something like this:

Map stuff = CollectionUtils.asMap(new String[][] {
{"locale", "en"}, {"theme", "basic"}} );

There is nothing in Java that is called CollectionUtils.asMap(String[][] map) so we have to create this ourselves, but without the exposure to the Map construct in a higher level language like Groovy it would be less likely that we would create a method asMap() as in the example above just because we had not experienced or perhaps not understood the power of such an abstraction.

Hmmm, so why is this so powerful, well it has to do with expressiveness and preciseness. Math is an excellent example of how you can cram vast amounts of precise knowledge together to describe a phenomena in nature... but just as Perl its syntax is quite obnoxious. I think I like math more :)

The way of Scrum

Was talking to my good friend about planning a software project and I wrote down this little overview on how I tend do it but it could change from one project to another...

Initial setup
You do an initial inception/elaboration phase where scoping takes place. Not all requirements are gathered here through. Maybe 30%-40% of the major ones.

Then for each sprint (iteration) you do analysis, design, development and testing over and over again. You find more requirements here maybe around up to 80%-90%. You should do integration here progressively.

Rule of thumb NEVER WAIT UNTIL LAST MOMENT WITH integration, testing, security and so on.

Then in the Closure/Transitional phase you complete/finalize the project.


Details around Scrum and Agile project development
So lets say you have a 4 week sprint (with is the name of one iteration when)...

So each software component would have to be broken down into smaller chunks that each should not take more than 8-16 hours (1-2 days) to complete. With completion here I mean:

Analyzed, designed, implemented and tested.

Backlogs
The team of stake holders would sit down and decide what the project should deliver. The following artifacts are produced:

Product Backlog - for the whole product (very high level, specifies the complete product)
Release Backlog - for a particular release (more details added, subset of the product backlog, for a release say v1.5)
Spring Backlog - features picked for a particular sprint, subset of release backlog (1 iteration worth of features)

The process and phases
So the Scrum project is divided into the following phases:

1. Review release plans (done by developers, picking from the backlog)
2. Distribution review and adjustment of product standards (done by developers)

This is where the majority of the work is done

3. Sprint (developers doing work, 4 weeks typically)
4. Sprint review (by stakeholders to determine next sprint, determine completion based on complexity and feedback)

5. Closure (last finishing activities, debugging, optimization, marketing and release)

So lets say for a 5 sub-projects and 5 components gives you 25 items in your backlog

So given that you have 5 months to complete the project you can break down the backlog into roughly 25/(4/20) = 125 chunks per sprint. So say you have 5 people in our team then each developer will work on around 25 chunks per iteration. That is your backlog "Burndown" rate... something called the project velocity in XP and other agile methodologies.

You need to be able to keep track of the Velocity in order to be try to track how the project is progressing. You need this as you would want to to be able to check your estimates... So lets say that one spring your velocity is 25... then if you calculating backwards you will find that you will be able to do 125 chunks based on having a team of 5 developers. But say that for one sprint your velocity is only 15 then you know that for the same number of developers you can only deliver 75 chunks so that will be your estimation baseline for the next sprint... So by using these instruments you can adjust the project plan and sprint backlog accordingly.