On Borland JBuilder 2006
It's a collaborative thing
Preview We've always liked Borland's JBuilder IDE for Java, especially as it is part of a pretty complete Application Lifecycle Management platform.
Borland's Application Lifecycle Management (ALM) platform ranges from requirements and process management through to (with the help of Mercury) testing. However, now comes JBuilder 2006 and we can't help wondering what is left to do in the IDE at the coding end – surely the real problems today are elsewhere, with requirements management and with aligning development with the business?
So, we asked Jon Harrison, EMEA product manager for Java products, what is so special about JBuilder 2006. His answer, in essence, is “collaboration”, which does make sense. eXtreme Programming and the Agile movement have done a pretty good job on the dynamics of local team-based programming but the reality today (in some places at least) is the geographically-dispersed remote team.
Some companies are outsourcing coding off-shore, others are setting up internal coding centres of expertise in places like India, and there is a lot of sense in “follow the sun development” (when your coders go to bed in the UK, QA picks up the baton in Australia, ready to return issues to the team when it gets back in next morning). Then, there is always the coding genius who simply doesn't want to leave his home in Smallville USA just because his or her employer chooses to set up its HQ on the San Andreas Fault – and why should he?
So, geographically-distributed programming is a reality and team productivity, including such teams, is Borland's main objective for its latest release of JBuilder. Within the JBuilder environment, Harrison says, you can access things like requirements repositories and configuration management solutions, all surfaced in the JBuilder IDE.
Anything surfaced is a target for sharing and collaboration, he claims, although he acknowledges that this isn't a suitable replacement for face-to-face contact in all circumstances. Nevertheless, he thinks that it allows people remote from each other to get some of the benefits typically associated with, say, pair programming.
Of course, it's been possible for some time for several developers to view the same project and talk through problems on the telephone.JBuilder promises something more, involving tracking and exchanging control of the session: "Suppose you're working on a particular piece of a project with a colleague," Harrison explains, "you're doing a debug run trying to understand what is going on with a particular piece of the code, stepping through the code, looking at the variable values etc...
"What you can do in JBuilder now is share that debug cycle - both of you can see exactly what's happening and then you can hand over what we call the “token” to your colleague, so that if you get to a part of the code he's written or has more knowledge of, he can take control and start stepping through and explaining himself," John continues, "and it's not just two people, 3, 4, 5, any number really, of people in the team can be doing this...”