Calling all blokes and sheilas– this year’s Asia-Pacific CITCON will be in Melbourne, Australia on June 27th & 28th– registration is now open so claim your spot before space runs out (space is limited to the first 150 tall poppies, surfies, and all around dags)!

If you dream about CI, yabber about TDD, live for BDD, or constantly think about automated deployments, then the Continuous Integration and Testing Conference is a ripper of a time, mates! The conference is free and is run as an OpenSpaces event, so there’s no reason not come. Remember, space is limited so sign up now!

This year’s North American CITCON will be in Denver on April 4th and 5th– registration is now open so claim your spot, this instant, before they run out (space is limited to the first 150 people)! If you dream about CI, talk in TDD, live for BDD, or constantly think about automated deployments, then the Continuous Integration and Testing Conference is for you!

I, for one, can’t wait to go, as the last time I went, I met great people and learned a load of new things too– it was the best two days I’ve ever spent in Texas! Plus, the conference is free and is run as an OpenSpaces event, so there’s no reason not come. Remember, space is limited so why are you still reading this and why aren’t you you signing up this instant?

We’re hiring! Come work for the fastest growing Agile consultancy in the mid-Atlantic region. We’re seeking Senior Consultants with Java experience for immediate Agile consulting work.

As a Senior Consultant for Stelligent, you will help transform customer teams through Agile methodologies, build expertise in the latest tools and technologies, and work closely with established Agile experts.

We are currently seeking candidates with:

• At least three years of Java development experience
• Experience in all phases of the software lifecycle
• Ability to work and communicate in diverse client environments
• Knowledge of Agile methodologies (Scrum and XP)
• Experience with test driven development (TDD), developer testing frameworks and continuous integration (CI)

Stelligent values team players that are interested in other people and new knowledge, open about exchanging ideas and practical in applying skills towards solving problems.

If this sounds like you, contact us today and tell us why you want to be a part of our team!

There are myriad code metrics available to measure attributes of code, such as complexity, coupling, and length, but few are arguably useful. In fact, as I’ve stated before, Cyclomatic complexity is the most applicable metric out there for accurately determining risk.

Recently, a few smart individuals married Cyclomatic complexity with code coverage yielding an impressively helpful metric. They’ve dubbed the metric C.R.A.P and while you may shudder at its name, its accuracy will bring goose-bumps.

If you want to learn more, have a listen to JavaWorld’s podcast entitled “Alberto Savoia talks shop about C.R.A.P.“– plus, the guy asking Mr. Savoia all the questions (and chortling a lot) is me!

Do you live for Test Driven Development? Do you dream about implementing Continuous Integration? Do you like helping other people adopt these principles?

If you answered yes to these questions, you should consider working for Stelligent! We’re growing and are looking to build our team with superstars having solid software development experience (Java, .NET, C++, etc) and who live and breathe Agile techniques (like TDD and CI).

See our Employment page for more information and apply today!

There are some excellent articles and posts around the internet recently related to a question asked on LinkedIn about metrics and code quality. Specifically, the question asked was:

What are the useful Metrics for Code Quality?

The user goes on to state that

The quality of any software application will depend mostly on its code base and it’s important to know what might be the key metrics that help us to evaluate the stability and quality of the code base.

Many of the answers bring up excellent points, including different ways of viewing the question, such as taking the time to understand what attributes of code are related back to quality. For example, Michael Bolton aptly suggests you ask if the code is:

• testable
• supportable
• maintainable
• portable
• localizable

What’s more, further answers suggest coverage, code size, and other metrics as discrete measurements that can help gauge quality. These are all excellent answers; however, the answer turns out to be quite simple.

We have found time and time again that there is one metric that most appropriately relates to code quality: Cyclomatic complexity. If your code base has highly localized pockets (i.e. methods) of Cyclomatic complexity (or CC) your code will have issues (undoubtedly affecting quality how ever you define it) eventually.

In fact, CC affects arguably every attribute listed above (testable through localizable). Think about it for a minute: a method that has 27 different paths is next to impossible to adequately test, which means you’re going to have a doozy of time supporting it because it isn’t easy to maintain. Code that is littered with high CC is a blast to port as well (hopefully you’ve got deep pockets and customers that absolutely love you). Good luck localizing it too.



It turns out that the other metrics mentioned (such as code size) tend to correlate to each other– in fact, it seems that all complexity-like metrics point back to CC. Classes that have a lot of dependencies are usually big and big classes usually have big methods and big methods usually have lots of conditionals. Lots of conditionals mean a high CC value (CC measures paths through a method, such as from an if/else chain).

Code coverage is an excellent metric for ascertaining what code isn’t touched by tests and it happens to relate directly to CC because in order to reach 100% branch coverage you’d have to have a one to one relationship with CC (i.e. if a method has 27 different paths, you’d need 27 tests to reach full coverage). Plus, coverage can be unfortunately misleading and can provide a false sense of security.

The beauty of CC is that it’s one metric. One number is all you need to understand risk. You can then apply it in many ways. For example, we provide development teams with ratios related to CC (because CC precisely delineates complex methods it’s often helpful to relate it to other normalized metrics) that enable them to gauge quickly the overall health of a code base. When the ratios grow, things are getting worse and when they decrease, happiness ensues.

The definition of quality (and its associated attributes) as it relates to software has traditionally been quite hard to nail down (regardless if you are a customer or a developer); however, one thing is factual– complex code is a house of cards that will eventually collapse (via attrition, bankruptcy, ossification, etc). Finding complexity and proactively reducing it will lead to software that is more testable, maintainable, and supportable. And by the way, that happens to be the kind of software customers like.

For his latest Automation for the people installment, “Asserting architectural soundness”, Stelligent CTO, Paul Duvall, demonstrates how using tests such as JUnit, JDepend, and Ant can play a role in enforcing architectural reliability.

Asserting architectural soundness describes a technique to build checks into your build scripts to proactively detect violations while coding. Locating potential deviations as soon as they’re introduced, instead of waiting to flag problems after the fact, ultimately leads to better quality software delivered faster.

In addition, Scott Laningham, host/editor of IBM developerWorks podcasts, interviewed Paul about the software development need that he addressed in the article. Paul kicked off the interview by indicating that,

Over time software architectures tend to become brittle. The architecture that you think you have versus the architecture that you actually have, as its manifested in the code, is often different.

Whether you read the article or listen to the podcast (hopefully both!), you’ll undoubtedly carry away the need to take charge of your architecture by using a proactive build process.

Who cares about software metrics? As a Java developer, I do. Measuring certain aspects of my code lets me quantify my schedule, work effort, product size, project status, and code quality. Oh, and then my project manager cares too. If I don’t measure my current status (number of classes, dependencies to other modules, complexity, code coverage, defects as well as code smells - yes, we all know when we have code smells) and use the data to improve my code and my future work estimates, those estimates will just be guesses. And my project manager expects a little better than guesses.

Metrics is an Eclipse plugin that helps me take a holistic view of various aspects of my code. I use it on a daily basis to see how my project grows and if there are any deviations from the reference architecture. The plugin lets me take a closer look at:

• Number of Classes
• Method Lines of Code
• Number of Methods
• Nested Block Depth - Is nice, I like!
• Depth of Inheritance Tree - nobody wants to traverse a 16-node deep tree trying to find what they need. 1-5 maybe, but 16….too many levels…
• Afferent Coupling, Efferent Coupling - yea, whatever… we saw this here…same story…
• Cyclomatic Complexity - If my code is simpler than Paul’s does that make me look “simpler” too?
• …and more…

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site Metrics and point it to http://metrics.sourceforge.net/update
5. Finish the wizard and restart Eclipse
6. Download the sample solarsystem project from http://www.testearly.com/resources/agile/solarsystem.zip. Open the project in Eclipse. Note that this sample requires Java SDK 6.0.
7. Build the project
8. In the Package Explorer, right-click the solarsystem project and open the Properties dialog. Locate Metrics and check Enable Metrics
9. Rebuild solarsystem
10. Navigate to Window | Show View | Metrics | Metrics View
11. You are looking at a table of various metrics covering the solarsystem project
12. 
13. Feel free to dig down on each metric as it goes from source folder to package to class down to the method
14. Notice all metrics for this simple project are in blue and there are no exclamation marks in the source code indicating any problems. Let’s change that and make life difficult for ourselves.
15. Open the preferences page for Metrics and check Enable out-of-range warnings. Drill one level down to Safe Ranges, locate Nested Block Depth and enter 5 as the Max value. Similarly, enter 10 as the Max value for McCabe Cyclomatic Complexity
16. In a Java Perspective open PlanetUtil.java and add the following method:

    public void thisIsAComplexMethod() {
            if (true) {
                    if (false) {
                            if (true) {
                                    if (false) {
                                            if (true) {
                                                    System.out.println("This is a deeply nested if sequence.");
                                            }
                                    } else {
    
                                    }
                            }
                    }
            }
    
            if (true) {
                    if (false) {
                            if (true) {
                                    if (false) {
                                            if (true) {
                                                    System.out.println("This is a deeply nested if sequence.");
                                            }
                                    } else {
    
                                    }
                            }
                    }
            }
    }
    

17. Rebuild solarsystem and return to the Metrics View. You now see two red lines in the results table and an exclamation mark in the code editor. Clearly the new code failed the cyclomatic complexity and nested statements rules of Metrics and therefore was marked red. The cyclomatic complexity of the method is 11, while the if statements nest for 6 levels. Both values are out of the acceptable ranges we defined earlier.
18. 
19. Locate the Dependency Graph View icon in the Metrics View. It can be found on the upper right corner and it is denoted by four dots connected in a square. Click the icon to open the graphical dependency view of Metrics.
20. 
21. The packages in the project are denoted by boxes in different colors. Blue means normal relationship; red means cycles and orange denotes the selected node. There is also a circle in the middle, the tangle center, which displays the number of packages in a particular tangle and the longest walk. In general, the longer the walk the more layers are involved and therefore there may be refactoring opportunities. Similarly, the existence of red nodes and tangles indicates cycles in the package dependencies and that’s also something that may be avoided with a little care. Finally, every node and the tangle center provide right-click menus to drill-down for more details.
22. The reason for this tangle (cycle) is the JUnit test PlanetUtilTest, which is located in com.solarsystem.jupiter. Let’s do something about this.
23. In the Package Explorer, locate PlanetUtilTest, right-click and select Refactor | Move. Move the test into a new package com.solarsystem.test.jupiter.
24. Rebuild the project. Open the Metrics View. Click the graph icon. Everything should be blue. There should be no tangles. No tangle centers. Blue is better than red. Life is good…
25. 
26. Enjoy.

Paul Duvall and Levent Gurses have posted a vidcast (video podcast) discussing Levent’s presentation at the Better Software Conference next week in Vegas. Levent’s talk covers Eclipse and how a carefully selected set of plugins (JDepend4Eclipse, Checkstyle, Coverlipse, PMD, and Metrics) can help you create better quality code.

If you can’t check out his live presentation in Vegas, simply have a watch below and let us know what you think. Enjoy the show!

What does dependency analysis mean to you? To me it mostly translates to the fact that Common Services (CS) packages should not depend on any of their clients. Does that happen in practice? More than enough to make the case for dependency analysis.

Just like the other tools in this series JDepend can be used in Eclipse or as part of a Continuous Integration cycle. I like to see what’s going on in terms of dependencies and other architectural metrics all the time, so I use both. JDepend calculates:

• Total number of classes and interfaces - number of concrete and abstract classes (and interfaces) in the package is an indicator of the extensibility of the package. How many?
• Afferent couplings (Ca) - number of other packages that depend upon classes within the package is an indicator of the package’s responsibility. Who depends on me?
• Efferent couplings (Ce) - number of other packages that the classes in the package depend upon is an indicator of the package’s independence. Who do I depend on?
• Abstractness (A) - the ratio of the number of abstract classes (and interfaces) in the analyzed package to the total number of classes in the analyzed package. The range for this metric is 0 to 1, with A=0 indicating a completely concrete package and A=1 indicating a completely abstract package. How abstract I am? If I change today, how many of my dependents have to change with me?
• Instability (I) - the ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package’s resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package. How stable am I? Do I change often?
• Distance to Main Sequence (D) - the perpendicular distance of a package from the idealized line A + I = 1. This metric is an indicator of the package’s balance between abstractness and stability. A package squarely on the main sequence is optimally balanced with respect to its abstractness and stability. Ideal packages are either completely abstract and stable (x=0, y=1) or completely concrete and instable (x=1, y=0). The range for this metric is 0 to 1, with D=0 indicating a package that is coincident with the main sequence and D=1 indicating a package that is as far from the main sequence as possible.
• Package dependency cycles - dependency cycles are reported along with the hierarchical paths of packages participating in package dependency cycles. If I depend on you and you depend on me, we have to work hard to adapt to each other’s changes, don’t we?

The JDepend4Eclipse plugin is an implementation of the JDepend tool. It follows the same principles and provides visual analysis inside Eclipse. One thing to note is that the plugin works on compiled java bytecode, so its important for your project to build. Related to this is the fact that if you’re following the same package/folder structure for your unit tests as your source code it might be a good idea to compile them into a separate output folder, separate all unit tests into another Eclipse project or just change the unit test package names (by appending the name test for example ), like I show below.

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site JDepend4Eclipse and point it to http://andrei.gmxhome.de/eclipse/
5. Finish the wizard and restart Eclipse
6. Download the sample solarsystem project from http://www.testearly.com/resources/agile/solarsystem.zip. Open the project in Eclipse. Note that this sample requires Java SDK 6.0.
7. Build the project
8. In the Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
9. In the newly opened JDepend perspective click on com.solarsystem.jupiter. Notice how the dependencies, packages with cycles, efferent and afferent dependencies and the metrics views get populated
10. Notice in the Dependencies view that the com.solarsystem.jupiter package has 3 Concrete Classes (CC), 1 Abstract Class (AC), 4 Afferent Dependencies (Ca) and 7 Efferent Dependencies.(Ce) Also the Abstractness (A) is 0.25 while the Instability (I) is 0.63. Finally, the Distance (D) to the main sequence is 0.11 which is denoted by a green dot in the Metrics view. Also in this view, notice that the package is marked as having a cycle. This is because the unit test PlanetUtilTest resides in the same package. JDepend works on compiled java code and therefore it picks up everything in the target/classes folder, including any unit tests. There is plenty of theory behind the various metrics gathered by JDepend and they are beyond the scope of this quick tutorial. It suffices to say that for any given package the shorter the Distance (D) to the main sequence, the better. In the above case the com.solarsystem.jupiter is used by four other packages, thus Ca=4. The package depends on 7 other packages, including junit.framework, therefore the Ce=7.
11. 
12. Generally speaking cycles between packages indicate complex interdependencies and should be avoided. In this step, let’s eliminate the cycles in the project.
13. In the Package Explorer locate src/test/java anc right-click on PlanetUtilTest
14. Select Refactor | Move…
15. Create a new package com.solarsystem.test.jupiter and click OK
16. 
17. Return back to src/main/java. Right-click and select Run JDepend analysis. All cycles are gone. While we eliminated the cycles, notice also that the distance jumped to 33 from 11 and is now denoted by a black dot.
18. In Java Browsing perspective select File | New | Interface. Enter a name, IBogus, select the package com.solarsystem.jupiter and click OK. This is just an empty interface.

    package com.solarsystem.jupiter;
    
    public interface IBogus {
    
    }
    

19. Build the project
20. In Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
21. Notice the Distance is now 16 and the dot turned green. But what did the IBogus interface add to the package? Nothing. It just fooled the tool. This is where special care must be taken. Sometimes emty or unused abstract classes can negatively impact the static analysis and make one belive that the package is in a better state than it actually is. My recommendation is to use other tools that detect unused classes and imports and get the whole system cleaned-up before each dependency analysis.
22. Enjoy.