By Janice J. Heiss
Published February 2012
This series of interviews spotlights Java Champions, individuals who have received special recognition from Java developers across industry, academia, Java User Groups (JUGs), and the larger community.
Michael Hüttermann is a developer and coach on Java/JEE, SCM/ALM, SDLC-Tooling and agile software development. A Java Champion, he is certified as SCJA, SCJP, SCJD, and SCWCD, and he is a member of the JCP and Agile Alliance, a java.net JUGs Community Leader, and the founder of the Cologne Java User Group. His book, Agile ALM, recently hit the market, and he led the Tools for Agility track at Agile 2009.
Oracle Technology Network: You have described ALM as consisting of approaches for Java developers who want to integrate flexible agile strategies and lightweight tool chains along software development phases. You argue that the effect is a more comprehensive and practical approach to build, configuration, deployment, release, test, quality, integration, and requirements management.
But doesn’t ALM cause vendor lock-in and increase the overall cost of an application? How do we balance the pluses and minuses of Agile ALM?
Hüttermann: Exactly, traditional ALM can cause vendor lock-in. My definition of Agile ALM addresses this issue. Agile ALM should result in processes and tool chains that are flexible, open to change, and high in quality. Some organizations use ALM single-point solutions; others feel more comfortable with an orchestration of single best-of-breed tools. Both scenarios have their advantages and drawbacks. Too much complexity is a potential risk in both cases. The goal of Agile ALM is to minimize accidental complexity. Relying on lightweight tool chains can dramatically improve flexibility, because you can easily replace small units of the overall infrastructure without touching other parts. And above all, in many cases, relying on Agile ALM will dramatically increase developer happiness because doing so provides structure for agile software development ("Agile").
Oracle Technology Network: How would you compare ALM practices and tools today with what existed four years ago?
|“Many tools are no longer cumbersome, monolithic vehicles—instead they really support the development process. An Agile ALM tool no longer needs to cover all facets of the ALM ecosystem.” |
Hüttermann: The biggest change is that "Agile" is more and more part of the solution. Most ALM tool suite vendors even name their products "Agile ALM" tools. Although we should be a bit skeptical regarding the massive overloading of the word "Agile," this is a good sign. Many tools are no longer cumbersome, monolithic vehicles—instead they really support the development process. An Agile ALM tool no longer needs to cover all facets of the ALM ecosystem. Using mashups of lightweight, focused, service-oriented, customizable tools has gained more and more momentum.
Oracle Technology Network: You have argued that, above all, Agile ALM is a discipline and a mental approach. What mind-set and discipline do developers need in order to function effectively using it?
Hüttermann: Agile ALM provides structure for Agile. It’s up to the people who implement Agile ALM to apply Agile values (such as respect and open communication), Agile strategies (such as continuous integration, continuous inspection, and continuous deployment), and Agile processes (such as Scrum). It’s very important to be open-minded regarding the tools you use and to be free to switch from one tool to another. This is part of the continuous improvement process in which developers reflect continuously about what the team is doing and how to improve. Being open-minded regarding tool chains means that you should monitor the market and switch from one tool to another one without being forced to significantly touch other parts of the overall tool chain.
Oracle Technology Network: What would readers learn from your book, Agile ALM?
Hüttermann: My book, Agile ALM, introduces a new vision for streamlining the development process through strategies such as task-based development, continuous integration, and practical Scrum implementation, plus it discusses collaborative development, functional release management, and technical release management, and it provides answers to questions of interest for stakeholders across all typical project phases. Besides the strategies, I explain how to implement exemplary strategies with best-of-breed tools and tool chains. This information can be appealing for motivated beginners as well as experts who already use tools.
Oracle Technology Network: The British writer George Orwell famously presented five rules of good writing—and then added a sixth: "Break any of these rules sooner than say anything outright barbarous."
Fellow Java Champion and expert on performance tuning Kirk Pepperdine has said, “A while ago, I added a slide to my presentations that says, ‘Everything I'm about to tell you will be wrong.’ I say this because, as time marches on, tips grow stale and things need to be reassessed. What’s even scarier, some tips are just plain wrong to begin with. Think of it this way: The prescription drug that your friend is taking may result in ill health if you were to take it. Same goes with performance tips.”
I’m wondering if you have advice about how it might be necessary for people to ignore some of your approaches at times.
Hüttermann: I hope that my recipes, understood in context, will be valid for many years. On the one hand, my book reflects the status quo—for instance regarding polyglot programming, cloud computing, and DevOps. On the other hand, I'm sure that no project will be able to neglect reality in the future. Thus, Agile will play an even more important role in the coming years. Of course, what we'll change is the tooling. Other tools will enter the market, while existing ones will catch up. That's the normal development cycle that leads to my recipe for establishing a mental approach that evolves. Even if you change single tools in overall tool chains, the concepts will stay the same, and the single tools can be changed with other tools. My book covers tools in a coarse-grained fashion. My examples do not rely on specific APIs or specific features that would change significantly in future versions of those tools. Instead, my book focuses on the big picture and provides advice about how to implement strategies with tools.
Oracle Technology Network: You probably would agree that some groups and projects work better with more structure, and some work better with less—and there can be many factors that influence this. Could you say something about in which domains of software development there is more leeway for looser structure?
|“In complex environments (distributed teams, complex application, advanced requirements for compliance), it's essential to use an integrated tool chain that glues together the best-of-breed tools to serve all stages of development in an end-to-end approach.” |
Hüttermann: Yes, I agree. In an environment with straightforward and simple organizational drivers (such as team size or organizational distribution) and less regulatory drivers (such as application complexity or governance), you’ll be fine with pragmatic approaches and pragmatic tooling. If the density of those drivers increases and, thus, the environment and basic conditions get more complex, your approach should evolve to use best-of-breed tools with an end-to-end integration. In other words, there’s an interdependency between complexity and tool usage: In complex environments (distributed teams, complex application, advanced requirements to compliance), it’s essential to use an integrated tool chain that glues together the best-of-breed tools to serve all stages of development in an end-to-end approach.
Oracle Technology Network: Give us a rundown of the lightweight tools that have become so important in Agile ALM in recent years.
Hüttermann: There are many examples. One appealing tool chain integrates JIRA, Hudson, Eclipse, Mylyn, and FishEye. This tool chain fosters task-based development spanning different project roles and project phases. Another interesting chain is to connect Java with Scala and Groovy in order to leverage specific features of different languages on the Java Virtual Machine (JVM). This can be helpful, for example, for setting up an environment for specifying and developing software collaboratively. Scala, with the specs2 library, and Groovy, with the easyb library, are examples of writing acceptance tests or applying behavior-driven development on the JVM where programmers and testers share the same infrastructure and are, thus, forced to work together closely.
Oracle Technology Network: Tell us about BDD (behavior-driven development).
Hüttermann: BDD is a special approach to writing acceptance tests. BDD-flavored acceptance tests focus on the expected behavior of the software. They deliver software specifications by defining example user scenarios. But BDD offers more if you put it into context. Running your specifications continuously, as part of your continuous integration ecosystem, leads to living (always up-to-date) software documentation. As a consequence, BDD helps to overcome barriers between testers, developers, and the customer.
Oracle Technology Network: Give us your impression of the various alternative languages for the JVM.
Hüttermann: There are many alternative languages on the JVM. I especially like Groovy and Scala, which I've included in my book. Groovy is a low-ceremony, dynamic language that excellently integrates with Java. Great tooling is available, and Groovy itself has involved tooling. For example, Gradle is based on Groovy and is a great build system. I like Scala because of its powerful mixture of object-oriented and functional aspects. As a statically typed language with a more academic background, it has features that enable it to be a good complementary language, especially for advanced users who feel that the innovation speed of mainstream languages such as Java is too slow.
Oracle Technology Network: Where in the process of programming do you have the most fun?
Hüttermann: There is no specific part of the process that I like the most. I like many different aspects from designing, developing, and testing to delivering software, because they all belong together. Because software development spans so many different activities and phases, and project members should collaborate closely to benefit from the best solution possible, I focus on the complete “application lifecycle.” Above all, software is made for and by humans, so it’s great to be in contact with many different stakeholders while working toward a solution.
Oracle Technology Network: The Java class that you couldn't live without is...?