Richard Searle's Blog

Thoughts about software

Further observations on IBM’s Liquid

Posted by eggsearle on May 8, 2011

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
The Mythical Man Month , written in 1975, describes how such benefits are unlikely to materialize. 

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.

Advertisements

3 Responses to “Further observations on IBM’s Liquid”

  1. James White said

    I’m not sure if you are still monitoring this blog post considering its about 6 months old, but I was approached to join the IBM Liquid Program and originally thought it might be a good way to make a few extra bucks on the side, and get a little more experience with IBM based products. Do you know of anyone whose done the program? Any insight you can share? I can see where this model could screw developers who are either worked for IBM and are now contractors or used to full time perm jobs, but the model works for someone like me who just wants a little extra money.

    • eggsearle said

      My discussion was purely concerned with the consumer of Liquid generated artifacts (aka the customer), rather than the developers.

      Your comment validates my concerns. How can a non trivial software system be created using developers who are only participating “making a little extra money”?
      One might argue that standard development teams are made up of people who are expecting a lot of money (which is of course the driving force behind the design of the Liquid program). However a good team is motivated by much more than a pay check.

      • James White said

        Yeah, I agree to a point. Sure I could use the money, but at the same time I’m not doing this just for the money. It is an opportunity to learn something new and different and work with IBM Products. I would venture to guess most people involved with the Liquid Program are doing the work to do a good job and as you mentioned a good team is no less financially motivated than a Liquid Participant. So to make it seem as though a good team is not as financially motivated as a Liquid Participant is just naive.

        I do understand the money factor though. I’m looking at some of these jobs and a good team or good developer would require far more money to do a lot of the type of work IBM wants done. I have gone forward with at least giving this program a try, but I am still very conflicted about what it represents to the tech industry as a whole. But before I completely condemn this model, I want to at least try it and see if there is any merit to it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: