Feeds

The Eclipse conundrum

Integrated development environment posers

  • alert
  • submit to reddit

Reducing security risks from open source software

Comment Eclipse, as a development platform, is taking the Java development world by storm and is likely to prove the IDE (integrated development environment) of choice for that community for some time to come or, at least, until something better comes along.

However, Eclipse provides a conundrum for CIOs and managers of IT development teams. The reason for this is that Eclipse guarantees interoperability between the different plug-ins that are available, and provides a common (up to a point) look and feel. Let's take this another step: Eclipse means that you can take any of, say, 15 different coding environments and plug them into Eclipse and they will all work not just with the other development tools that you use, but also with all of the other coding environments.

In other words, it would be perfectly feasible to have a development team, each of whom used a different coding environment. Indeed, there would be nothing to stop any individual using multiple coding environments, perhaps because he or she preferred this tool for web applications, and that one for building web services, and a third for something else.

Now consider this proliferation from a management perspective. Is this a dream or a nightmare?

Before we even attempt to think about this, there are some constraining factors we should consider. For example, you could just as easily have multiple requirements management products or multiple software configuration management solutions. However, if you did this, then how would you keep track of which tools were being used to manage which projects? You would need another super-management tool to manage the management tools – and, of course, you could have multiples of these - which would mean that you would need super-super-management - and so on - which is clearly daft. So, we must logically have some control over which management tools we use.

Another consideration is one of support. If you want to have formal support from a supplier, together with things like indemnification, then you are obviously going to need to limit the tools you use for cost reasons, though this does not, of course, prevent you from using other, unsupported software.

A possible counter-consideration is training. One can imagine a new development team being put together, in a few years time, made up of developers from a variety of different backgrounds. Each of these people is likely to be familiar with a particular toolset - why bother to retrain them, with all the costs and time involved in that process – why not just let them use what they want to?

On the other hand, there is another downside to the open-for-everything approach: developers like to play with the latest tools, and job adverts require up-to-date skills, so there is a danger that developers will use any open-handed policy more to increase their value in the job market than to do the job in hand.

So, you can see the issues involved and you can probably think of even further ramifications (it certainly has some for vendors). Unfortunately, I cannot say that I have any solutions to recommend and in any case, they will probably vary from company to company. But a clear Eclipse (and, indeed, Open Source) policy is going to be needed by any organisation pursuing this development route.

Related stories

The Power of One eBook: Top reasons to choose HP BladeSystem

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.