How you do drive development? This was one of the questions posed by Helen Beal in her session on DevOps Driven Development and Delivery at JAX Conference 2017. In an industry where so many acronyms exist to describe the way we develop software, from the well-known (TDD, or test-driven development) to the lesser-known (HDD, or hypothesis driven development), it's important to remember that all of these concepts share a common goal: to deliver high-value, high-quality software.
When adopting Agile development practices for the first time, it is easy to assume that there is a correct way to do everything, and that we can guarantee success just by following the correct formula. Methods and processes are an important foundation, but we need to remember that they are descriptive rather than prescriptive. To maximise our potential, we need to continually evaluate and adapt the way we work to the problems at hand.
Ultimately, there are numerous ways in which we can drive development, but people and culture are central to all of them. No matter which approaches we take and which processes we use, we can improve only by recognising our mistakes, learning from others and harnessing our insights as a driver for change.
Being so close to the release of Java 9 (21 September 2017) it has come as no surprise that some of the discussions at JAX have involved the latest features and functionality of the release. While some of these new features have had obvious use cases, others have left me asking why I would use this.
An example of one of these features is Java's new read-eval-print-loop tool JShell. Initially I was enthusiastic about JShell: 'The ability to receive instant feedback on whether methods behaved as I expected? Sounds great. I'll be able to sanity check any new methods straight after writing them with minimal fuss.'
But then I had a thought; why would I not know what to expect from my methods? Why would I need to 'sanity check' them? In Test Driven Development (TDD) I would have written tests that cover all the functionality of my class before I even begin to code. I should already know the expected functionality of a method based on whether these tests pass or not. To put it another way, my tests will already be giving the instant feedback mechanism that JShell provides. By using JShell in this way, I am admitting that I have not defined all the tests up front and therefore am not fully committed to TDD. I came to the realisation that JShell wouldn't be able to help me with day-to-day programming without violating TDD principles.
So, if we shouldn't be using JShell within day-to-day programming, what should we be using JShell for? JShell is both quick and simple to use. You don't need to go through the cumbersome steps of creating a Java application in order to start writing Java code, nor do you need to write test classes to validate that your code is correct. Instead, you can start typing immediately, using JShell's instant feedback to check Java syntax and expected outputs.
I believe JShell has a place as a learning and teaching tool. New Java developers can use it to learn the basics of Java without getting bogged down in things like main methods or concepts such as classes. Experienced developers can use it as a demonstration tool to highlight new features of a program quickly without having to run a test class to prove they work. Dr Raoul-Gabriel Urma and Dr Richard Warburton presented a JAX talk using only JShell to demonstrate new Java 9 features to great effect.
To conclude, while JShell provides an easy entry point to new developers, experienced developers who follow TDD principles may find their use for it quite rare. Perhaps, once the Java 9 dust settles, new interesting ways will be discovered that will thrust JShell into day-to-day programming. For now, JShell will have to remain as a neat little entry point into the world of Java.