Welcome!

From the Editor of Eclipse Developer's Journal

Bill Dudney

Subscribe to Bill Dudney: eMailAlertsEmail Alerts
Get Bill Dudney via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Enerjy Software Discusses Enerjy CQ2

Enerjy's new CQ2 Product Interview

JDJ: Describe the focus of the Enerjy CQ2 product and the target user base.
Enerjy Team: In the past we have focused on developers and built tools to support them. What we have found is that while these tools are helpful to developers that understand the importance of upfront quality practices the tools do not provide the development managers a way to prod developers that are not convinced. Enerjy CQ2 provides managers with the same insight into the whole code base that individual developers have on the code they are working on. This gives the managers insight into the code as its being written. Instead of managing problems as they come up it gives managers the ability to manage risk up-front. With the tool set managers can identify violations of the standards as well as attribute that code violation to an individual developer.

JDJ: Aren’t developers offended by managers approaching them with coding violations?
Enerjy Team: Well of course many developers believe that they write perfect code but the fact remains that many projects are late or never actually go into production and many of these cases are due to failed quality practices. We have found that most of the time senior developers see the analysis as a ‘safety net’ and junior developers see the statistics as a way to learn. Besides, it is hard to argue against testing. We have talked with many developer managers that have recently introduced coding and/or testing standards, we have found that typically senior developers are proud of their metrics and junior developers are motivated to do better. So no we don’t see a major problem with developers being offended by these metrics. We also provide a way for developers to self-audit so their violations need not ever be seen by a manager.

JDJ: You mentioned testing standards, what are some examples of the metrics you track in this area and does the information the developers see vary in any way from what the manager sees.
Enerjy Team: Well we gather and report metrics in two basic areas, static code analysis and testing coverage. For static code analysis we have an Eclipse plugin that will help the developer see any violations up front. For testing analysis we use a code coverage tool as well as make sure all methods have a test. The managers and developers can see the same information, the managers with CQ2 and the developers with the self-audit tools.
We also group analysis points into levels, high, medium and low. An analysis point such as ‘all unit tests passing’ would be high while ‘tabs instead of spaces’ would be considered low. The developer manager can then manage to these metrics but the developer is never broadsided because they have access to the same information as they write the code.

JDJ : So what tools do you expect the team to use, is there any requirement for the developers to learn a new tool set?
Enerjy Team: No we don’t expect the developers to learn any new tools, we want the developers to remain using the tool set they are comfortable with. We do expect that the team is using a version control system (CVS, Subversion, and Perforce are currently supported with more planed) and that JUnit is the used to write the tests. Other than that the developer will not have to learn anything new for the managers to be able to perform analysis on the code base.

JDJ: Do you currently support any other phase of the development lifecycle other than coding?
Enerjy Team: No we are focused on the development/coding phase, there is no real way to get involved in the requirements management phase without imposing a lot of changes in the way a developer works and imposing a lot of process on the team. We choose to focus on the development part of the lifecycle.

JDJ: What do the reports that the development manger gets look like, what kind of information is available.
Enerjy Team: The manager is first presented with a trend graph showing how the project is doing over time. So she can see if the trend is in a positive direction or negative. If there is an identified problem the manager can drill down into the detail all the way to a particular line of code if need be. The other interesting aspect is that through the version control system we are able to let the manager know exactly who is responsible for the introduction of the issue. So over time the manager can see if a particular developer is improving, getting worse or staying the same as well as what kind of issues are be introduced.
We have found that companies really like this as a means of bringing new hires up-to speed on company practices. With a self-audit the new developers can see where they are going astray from the teams practices.
The other interesting aspect is that managers don’t have to use Enerjy CQ2 from the onset of the project. Instead the history stored in the version control system (CVS, SVN etc.) can be used to develop the projects metrics.


More Stories By Bill Dudney

Bill Dudney is Editor-in-Chief of Eclipse Developer's Journal and serves too as JDJ's Eclipse editor. He is a Practice Leader with Virtuas Solutions and has been doing Java development since late 1996 after he downloaded his first copy of the JDK. Prior to Virtuas, Bill worked for InLine Software on the UML bridge that tied UML Models in Rational Rose and later XMI to the InLine suite of tools. Prior to getting hooked on Java he built software on NeXTStep (precursor to Apple's OSX). He has roughly 15 years of distributed software development experience starting at NASA building software to manage the mass properties of the Space Shuttle.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.