Assimilator 1.1 Release

I just released Assimilator 1.1 on Sourceforge. This release contains:

  • corrected script to properly accept parameter designating codebase location
  • JMX interface added to Monitor, Cybernode and Webster core services
  • drag and drop of oar files onto console service graph to deploy services added
  • corrected oar deployment code to handle operational strings with Include tags allowing deployment of dependent operational strings.
  • removed old viewer and opmon utility code, documentation and build file references.
  • changed helloworld example files and documentation to consistently use steps 1-6.
  • new webster using MINA 1.1.4 (JDK 5 version) and integrated it
  • moved jini ServiceStarter class to assimilator and modified it to add loggers from top level config file (we had a really hard time get jini loggers to turn on properly before and this should fix it), quite a bit or exception refactoring and other general refactoring
  • moved all the script and config files to use the new service starter and new webster.

The new distribution file can be downloaded here.

In the works is a network overlay for Assimilator so that distributed services can be managed over the internet.


Passing Objects Around Networks

With the advent of XML has, in some cases, come the overuse of it for transferring information between endpoints in a distributed networked environment. It’s true that XML and Javascript Object Notation are more interoperable allowing multiple languages to be used for application development between client and server. It is also more human readable which mostly doesn’t matter except for simplifying debugging during development. I just don’t quite understand why the social realm of developers chose primarily to adopt XML over transferring the bytes of serializable objects without having to transform it to readable characters.

Binary is more efficient for serializable objects. There is less transformation required at endpoints before and after transferring data around. Less code and libraries are required to develop and deploy the distributed components of an application. Maintenance of the code is typically easier. And more sophistication can be applied in the passing of serializable object as method parameters, return values and exception handling information. Java RMI for example with its use of stub/skeletons provides the mechanism to invoke functions on remote objects which is truly more powerful than making http requests with XML data.

I suppose it’s likely that XML is just easier to use for now. The tools and IDE plugins were easier to develop and came faster than any tools to support building applications with remoting capabilities. Http and XML are just easier to deal with than configuring EJBs. Although EJB3 components are now much easier to deal with since the wiring is largely defined using annotations.

From the perspective of distributed computing being web servers scattered everywhere, it’s likely XML and RESTful style web services will continue to dominate. True next generation distributed computing capabilities where all computers are peers will require greater sophistication to handle mobile code, mobile services, service discovery and the transfer of data between the services. It’s not going to be HTTP and XML!

Crummy Scrum Development Process

Having been on a number of different projects attempting to use Scrum in multiple organizations, I have noticed recurrent patterns of it being applied incorrectly. The decision to use Scrum (or in some cases force its use) is well intentioned. But when the rubber meets the road and a project gets underway, typically teams find out Scrum is more difficult than originally thought. This leads to skipping parts of or trying to shortcut the methodology and process. This results is the team not reaping the benefits Scrum has to offer and gives the impression to team members that Scrum doesn’t work. Here are some of the behaviors I have observed.

Skipping the Planning Session
I have seen this happen because the stakeholders, project managers and architects/engineers can’t or don’t want to all meet up to do the planning. I have also seen this happen when the primary project driver or stakeholder refuse to do nothing more than throw a bulleted list of ‘things’ desired at the development team with a completion date.

This results is an incorrect or incomplete set of backlog items for the team to deal with. Of course, this increases risk and probability of failure.

To help alleviate this problem a surrogate should be appointed for those key stakeholders and team members that can’t or won’t participate. Also the team can rally and not start any further work until a planning session is accomplished making it clear the non-participants are the road block.

Missing the Point of the Scrum
It is very common for team members to chat way beyond necessity during the scrum meeting. People just like to chat. It’s also common for members to talk about things other than their assigned tasks. I have seen scrums complete in the allotted 15 minute time box where none of the defined task were truly discussed.

This behavior unequivocally leads to a project out of control. Probably leads to the typical chaotic behavior that was being practiced before Scrum was mandated. There are a number of causes for this happening including the Scrum Master not enforcing proper behavior probably due to lack of training and experience with Scrum. It is also caused by the tasks not being properly defined. If a developer is discussing working on things other than assigned tasks, that person is either goofing off (probably not the case) or has identified another set of tasks which need to be captured. This probably means the backlog items weren’t defined correctly (see Skipping the Planning Session) or the project development has gone way off track.

It helps to have some training or an experienced person lead or help run the Scrum process. It is difficult to learn from scratch and stumble over all the typical mistakes. It also helps to scope the sprints short adding only a few backlog items with a small number of tasks. 2 weeks max for the sprint 4-8 hours max for each task.

Task Lengths Way Too Long
Defined tasks with a length greater than 12 hours means either you don’t have a good understanding of how to break down the task or you’re padding the time you think it will take so there is no pressure in completing it. Probably the former. I have seen task length definitions of 40+ hours.

Not taking the time to plan out the tasks and not making an effort to scope them properly does not help the project and defeats the purpose of using Scrum. Part of Scrum is learning how to estimate properly and learning the capabilities of the team. This knowledge helps in future planning sessions.

Assuming Nothing Changes
Change happens on virtually all projects whether or not you use Scrum. The fallacy is that once the project plan is in place nothing will change. Most management teams put in place a set of defined product features that is fixed. It is to be completed by a fixed date with a fixed set of resources. I have never seen a plan Not waver while in progress.

Scrum and Agile methodologies are specifically designed to help address changes during development. It’s ok to set long range goals but define short sprints, spend time planning them, use feedback from the sprint results and changes that happen during the sprint in a feed back loop during planning and expect anything may change mid-flight during development. You will be able to better adjust if you have flexible development cycles.

There are other wrong Scrum practices. These unfortunately occur frequently. If you plan on using Scrum, take the time to learn it first and decide if it’s appropriate for your organization. If you use it, make a concerted effort to follow the methodology correctly. It will be beneficial!