Essentially, it was the catalyst that got us to look at JBuilder again.  Internally, over the past several years, our developers have become proficient at developing on the Eclipse platform due to the large array of available plug-ins that increase developer productivity.  Without much re-tooling, our developers could move to JBuilder, install their plug-ins and be off and running.  Also, since we are Together users, by rolling the Together functionality into the Eclipse platform, we were able to get the best of both worlds.  There is just a high level of comfort with Eclipse for our developers and that makes the move to JBuilder very easy.

It is different for different engineers as they were approaching the software development cycle from different perspectives.  With our architects, who are familiar with Together, they were able to still use the Together features and not have to switch tools to get access to the various plug-ins like XML editors, GUI Builders, version control systems, etc.  Even within the development groups, they could choose what functionality they wanted and not have to have something dictated down from the top.  If a developer liked the functionality of a particular plug-in that nobody else was using it was not a problem as Eclipse does not pollute the code base with proprietary material.  The source stays clean and Eclipse plug-ins give the developers the view of the source that is comfortable to them.  Eclipse gives us a great deal of flexibility and covers a wide range of development styles and tastes.

Not sure this is really a specific technology hurdle for us, but our engineers are spread pretty thin across projects.  We are constantly in mutli-tasking and interrupt-driven mode.  Some days will be spent at our desk, working on a large J2EE project, while others will be spent in a pitching boat, debugging embedded controllers that are sitting 12,000 feet under the surface of the ocean.  Switching between these various contexts can be very costly and time-consuming.  With tools like Eclipse and JBuilder, we can communicate in a way that is familiar to all of our developers and this helps reduce the time spent in the switch.  Class diagrams, sequence diagrams, activity diagrams, code formatting standards, etc. all help the developer get a quick view into a project that they have not visited in quite some time.

 

Q. Do you make use of the LiveSource UML modeling tool? What for?

Absolutely.  We got hooked on LiveSource from the early Together days and have never been able to find anything that keeps the source and the model in such close synch.  We use it to both model and reverse engineer.  We have used it to model a wide range of components from data models for persistent POJO’s to GUI applications.  Other tools we have looked at all seem to have this conscious step of synchronizing the model with the code.  Outside of the cost of stopping to perform the synchronization, they would often get out of synch and it was difficult to get them aligned again.  You start to feel like you are wrestling with the tool to get it to do what you want, but with LiveSource, it is just constantly in synch and we never have to stop and think about the synchronization step.  A real time saver!

Q. How about the new collaboration features?

Oceanographic technology is undergoing a change in that what once was largely a project or lab focus is now turning more towards collaboration.  The approaches to solving problems are beginning to span multiple, projects, labs, institutions and countries.  Collaboration is key to our work and it ensures that we are building tools that help answer important scientific questions.  Because of this, both scientists and engineers find themselves in need of effective collaboration tools like Wiki, Blogs, Instant Messaging, etc.  We are finding those tools indispensable and although we have not leveraged them in JBuilder yet, they fit very well in our landscape of tools and I suspect will be picked up very quickly.

 

Q. MBARI emphasizes the peer relationship between engineers and scientists as a basic principle of its operation. Is this reflected in its use of technology in general, or of JBuilder in particular?

The relationship between scientists and engineers is paramount to what we do at MBARI and technology is both the enabler and product of that relationship.  Part of the mission of MBARI is to deliver tools that enable scientists to reach places they have never been to before and gather data that has, until now, been unattainable.  David Packard (the founder of MBARI) knew this was key to ocean exploration/research and without technology, ocean science would not be where it is today.  Our scientists are extremely open about trying new technologies because they have seen what can be gained from these tools and that helps in keeping the peer relationship healthy.  In essence, the science and technology are what we all gather around.  While JBuilder is not something that our scientists use, the artifacts (like models) are used to communicate the technology and designs to our scientists during reviews.  Some of our scientists are even familiar with reading UML!

Q. How about code testing, what’s the situation there?

As our systems grow more complex and cross many disciplines, we are finding testing to be key.  We are mostly working with unit tests and employ them in continuous integration cycles.  In this context they are indispensable because they catch problems early and often and make things like regression testing much easier.  Having a tool like JBuilder that provides unit testing, audits and metrics makes it easy to apply the knowledge of years of software development in a straightforward manner.

Q. What kinds of products and platforms do your apps have to run on? What’s the rough open source/proprietary balance?

 

We sit firmly in the world of open source.  One of our tenets is that our technology needs to be made available to the community to further ocean research outside the walls of our institute.  The ocean is a fairly accessible environment (compared with space for example), which makes ocean exploration exciting because it can be reached without monumental resources.  Most anyone with access to a body of water can do research and they will often not have the funds to buy expensive technology.  The biggest issue with the ocean is its under-sampling and by getting technology into the community’s hands, we can increase the amount of data gathered from the ocean.  If our products were not open source, it would often dictate what tools research groups would have to purchase, which would be a huge barrier to the exporting of our technology.  While we often have to use proprietary technology internally to further our applied research, we do our best to keep those out of our end products that we make available to the community.

Q. What’s the biggest emerging technology trend that you anticipate as being relevant for MBARI in 2008?

Wow, that is a VERY hard question to answer.  Our engineers have to be fluent in many technologies and there are exciting opportunities in so many domains.  One day may require researching DNA microarrays while another may be looking for new software frameworks to make web application development faster.  As boring as this sounds, I think productivity technologies and enhancements are going to be a huge boost for our engineering group.  Because of our breadth of science interests at MBARI as well as the responsibility of our engineers to find new technologies that will impact science, the faster we can design, prototype, and construct tools, the more scientific research we can enable.  Any time spent fiddling around with the infrastructure and development tools is time lost that could be spent achieving our mission.  Focusing on expanding our knowledge about the ocean is our bottom line and we are always looking for ways to get us there more quickly.