Mickaël’s Weblog

I’m having at look a GRails 1.0.1. I get a little problem after setup and here is a little trick to help you if you encounter the same kind of problem.

So I installed version 1.0.1 that you can download here. I’ve set up the environment variables and launched “grails” on the command line.

At that point I get some weird message as “Xxxx was unexpected at this time”. This was due to my JAVA_OPTS. To find the problem, just setup the DEBUG environment variable to anything you want.

This way you will see the content of the batch command executed and will be able to find the root cause of your problem.

You can have a look at it …but use firefox as the web site has some display problems on IE (or maybe this is due to my IE configuration).

Finaly the famous Rails framework enter in java world, that should provide excellent reasons to no more see this RubyOnRails video:

[youtube:http://www.youtube.com/watch?v=PQbuyKUaKFo]

A new desktop usability experience that worth to have a look at.  

…SF as Software Factory, I mean a full featured development infrastructure. This became obvious to me when I read the post of Ayende on his vision of entreprise platform.

Ayende had the idea to base the system on code versioning system. This is definitely a great idea that I share, but I think this should go beyond: a complete software delivery infrastructure. The customer (software providers in fact) should be able to build, test and deploy applications….services for others users.

The great idea to relly on a source control system will solve the problem as versioning of the applications (for a part of it) and when you have multiple developpers working on an application or service. But this does not fullfil all the requirement for a PaaS, what about tests & validation, deployment (especially for multi-tenancy), delivery, maintenance…etc.

Finally, the requirement is to provide to some users a full featured development and delivery environment. The excellent post on the Lack of good Paas platform is highlighting very well all these requirements: customization and configurability, versioning and multitenancy, security, scallability.

I would add a requirement on robustness: as soon as multiple users can deliver software on top of platform shared by all…there is a high risk to have the system out of control. Ensuring a high level of service is fundamental, so the system should be really robust. The challenge is to let the system open (the sw providers are building software - so very high level of freedom) and “a live”, but this will be the topic of another post.

Jimmy Bogard have written a very interesting post on Flexibility and control.

He is writting: “The manager had likely fallen under the illusion of rigid control leading to more predictable success.”

His image with arrow and guided missile is terribly true and helps a lot to understand agile concept. Has I’ve already written in a post on Agile Practices With Waterfall Management, management that does not embrasse really agility (maybe due to some misunderstanding), this can produce very weird effect.

What about Program and Development Management that are using a waterfall approach with agile development team? By waterfall approach for management I’m talking about management decision not to start the development before requirements are defined, planification and release date setup. It’s not unusual to see also a stabilization phase defined as for example the last couple of iteration.

This is mainly due to:

• Product Management team is not ready at all for the first iteration,
• Infrastructure changes not identified before the first iteration,
• Product Management wants to have a full plan on the future release before starting, to prepare pre-announcement.

The final result of this approach is that the development team is not working at all…because it’s simply forbidden. The market driven approach has been well understood by Product Management and they are blocking any kind of development before they have decided what features have to be implemented.

Joaquim Rendeiro talk about co-existence of waterfall (especially for management) and agile methodology in his post on Agile or Waterfall?. Yes, they can exist but may have the consequences I’ve talked about.

IMHO, this occurs inside teams that are transitioning to agility and are not mature enough on this agile approach. As agility provide a huge responsibility and control capability to the product management, they used this extra-strength keeping in mind the waterfall approach targeting dates and content of the releases.

The development management should be the driver to accelerate the transition to a real agile approach. For example by rejecting all big kick-off meetings to start a release, and encourage a better preparation of each iteration. The development team managers should also avoid any technical discussion include an product owner and take the responsibility to make the technical choices. Often, the technical choices are delegated to product owner. Yes this is strange, but haven’t you any discussion with a product owner like: we can implement the story this way and it will cost 13 points or a different way and it will cost 21 points but this last one is less good for reasons A and B. Let guess the answer…do the shortest path. Even if this is usually the good answer from a technical perspective (I’m supporting the principle of simple design which is often shorter to implement), there is not reason to delegate this decision to product owner.

Agile approach requires a clear definition and separation of responsibility for every shareholder.