Richard Searle

Agile

Liquid is described as agile. Liquid is also defined as requiring: well defined specifications and well defined parameters on what constitutes a successful outcome. The latter is pretty much a text book definition of a waterfall method.  That is further confirmed by a description of how the project architect uses Liquid to first generate the design specifications and then uses another Liquid contest to generate the implementation. The timescales are too short and the communication mechanisms are too short to permit anything other than a command-and-control, full waterfall, throw the design over the wall methodology.

Qualified Developers

The Liquid Players can be motivated by the opportunity to

1. Exercise skills just learned in class.
2. Prove themselves in pursuit of a new career opportunity.

The component created by such an inexperienced developer is to be integrated into the system, evidently as is. The credentials or certifications held by the Player  are described as irrelevant. This contradicts all other IBM policies, where certifications are mandated.

Scalability

It is claimed that the developer community has unlimited size, with the following benefits:

1. Project leader can start work sooner.
2. More work done in parallel.
3.  Reduced development cycle times

Communication

Architect and Player interact via IM in a chat room. This is marginally better than email in terms of interactivity.

Component base development

It is arguable that CBD is actually highly successful or widely used, outside of a few narrow contexts. A small two person year project will require at least 100 "components" to satisfy the needs of Liquid.  It is hard to see that such fine granularity will naturally exist within  the design.

Further Background

This https://researcher.ibm.com/researcher/files/us-msridhar/foser061-bacon.pdf paper describes some of the background behind Liquid.