ALM tools can tell you the truth about your code – but what if you don’t like what you see?

shutterstock_215665933Gloria Steinem once said “the truth will set you free…but first it’ll piss you off!” This reality frequently hits home with many organizations implementing Application Lifecycle Managment (ALM) tools. They find their velocity has slowed down, QA deploys have ground to a halt, and finger pointing has escalated to new heights. Worse yet, the valued metrics you have started collecting from the system appear to be telling you that you have more problems than you thought you had when you implemented the tools in the first place.

Weren’t ALM tools supposed to fix all of this? Wasn’t this supposed to usher in a new world of bug-free code, worry-free deploys, and skyrocketing velocity? Didn’t you tell us that implementing things like continuous integration and artifact repositories would help us work together better? Wasn’t it easier before when we relied on manual processes and tribal knowledge? What could be going wrong? Often times the answer is nothing is going wrong; the tool is simply doing its job and now it’s your turn.

The Virtues and Difficulties of Scripting Your Software Builds

I love writing build scripts. I do and I suspect that I’m the only one. Build scripts are the New York Times crossword puzzle of software development. The process of writing one involves taking what you know about the application, combining it with what you’ve been told about it, and filling in the gaps that are left over. Here’s the thing: a proper build script is always a living document. It is written in frequent, sometimes painful iterations and you can expect it to change with almost every major release of your application. Just because it successfully built your application today doesn’t necessarily mean that it will do that tomorrow without changes – sometimes major ones. To do this with the minimum amount of pain, it’s important that you follow the following guidelines:

  • Utilize best of breed build tools like Maven, Gradle, MSBuild, or Ant. They make the sometimes tedious practice of compiling and packaging code easy. They also have extensive support in modern development environments which will help you implement the next guideline.
  • Make the build script the backbone of the development process. Work with the development staff to encourage them to run and update the build scripts while they are writing the code so that issues with missing dependencies or configuration files are kept to a minimum.
  • Standardize and simplify your directory structures so that builds can be run anywhere. Tools like Maven and Gradle encourage this practice.

Why are My Tests Failing?

Once you have code that compiles and packages properly the next hurdle is unit and integration testing. Frequently, when we have implemented continuous integration tools for development projects we’ve been assured by the development staff that they have extensive unit testing set up. Almost every time, when we start to implement automated unit testing, 100% of the tests fail.

What happened? It’s likely a number of things. A common problem is there is a misunderstanding of the difference between unit tests and integration tests. Unit tests should be designed to run anywhere and quickly, with the bare minimum of external resources (databases, files, network resources). In situations where external resources are required, it’s best to implement in memory databases like h2 or mock libraries like Mockito or Easymock. In integration tests, live databases or other external resources are required, another frequent issue is utilizing hard-coded values for those resources that can’t possibly be created by a build script (try reading a file in c:\myapp on a linux box!). When this is the case, it’s best to implement external configuration files that can allow you to configure different resources for local developer tests and tests on a build server.

My Code Metrics are Terrible!

Code Coverage tools like Atlassian Clover or JaCoCo and dashboards like Sonarqube are essential building blocks to any ALM tool setup. They are the best ways to measure your progress in eliminating technical debt and to guarantee that you are testing your entire application. When they are first rolled out, however, they can frequently paint an ugly picture of your application. I once saw a sonar report that said that it would take over 5 years of work to eliminate the technical debt for one web application! Before you preemptively turn in your resignation, follow the following tips:

  1. If your application relies on code generated by a utility (code generated from WSDL files as an example), it’s best to exclude that code from your reports. You won’t be able to write tests for such code in any reliable way so it’s best to ignore it. As an example, when we did that on the application I mentioned above, the technical debt repair time dropped from 5 years to 2 months!
  2. Don’t panic. Technical debt is probably what brought you to implement these tools in the first place. Knowing what you have to do is still better than being in the dark about your problems.
  3. Rather than assuming you will fix these problems eventually in one big technical debt release, consider taking steps to remedy problems as you fix or improve features in your code and including it in your estimates. As the technical debt is eliminated, your velocity will improve and your bug count will drop – giving you even more increased velocity!

Maven Wave Can Help

The consultants at Maven Wave can help you overcome these challenges in a number of ways:

  • Help you implement your ALM tools properly to give you the most accurate picture of your applications and how to improve them.
  • Our agile process consultants can help you improve your estimation process and increase your velocity.
  • Our development staff can provide extra bandwidth, when necessary, to help you meet your deadlines while eliminating technical debt.

Implementing Application Lifecycle Management tools can give you the clearest possible picture of what needs to be done to improve the quality of your application. Sometimes the tools may tell you there is a long road ahead, but as you begin to improve your application and pay attention to what the tools are telling you, it will pay dividends with fewer bugs and increased velocity. With that, brings fewer long nights and increased innovation.

Written by Glenn Brown, Maven Wave DevOps Consultant. Contact us for more information.