This week will be a little bit of a reprise of some things I've spoken about before on the topic of IDEs and some tangentially associated things.

When we write software, we are using what some of the more flowery among us would like to call a workflow but that most of us simply refer to as our tools. We like to think that we use best practice in our work too, and that the best practice actually is worth using.

As I described before, there are some integrated development environments which aim to fulfil all the needs we have from our tools and in doing so, they often fix a particular workflow into place. In addition, some tools are more powerful (or, rather, more flexible) than others and that can create friction when we try to combine techniques and tools to produce a workflow which suits us.

As you may have guessed by now, I am writing about this topic because I was recently made exceedingly angry by incomplete integration between some very popular tools which I tried to make work together. I was attempting to write some Java code and these days (apparently) the build system to use for Java apps is Gradle and since I'm not a "native" Java programmer, I went with the recommendation. I prepared my codebase, wrote my gradle file, built up a basic set of classes, got everything settled the way I wanted and then decided it was time to properly write some code.

Now, in Java world, it's exceedingly rare to write code without the assistance of an IDE because, quite simply, Java is incredibly verbose in some places and IDEs make life a lot easier for dealing with the moment-to-moment boilerplate and refactoring pain. One of the two major IDEs for Java is JetBrains' IntelliJ IDEA and IDEA has integration for Gradle projects. I fired up IDEA, pointed it at my build.gradle and it chugged away for a bit and then opened up a project workspace which looked perfect. Sadly it turned out to be entirely worthless because while IDEA could read the Gradle file, examine my filesystem and decide what sources comprised my program, it was actually doing this in a way which didn't take into account that Gradle is in fact able to embed arbitrary Java and I happened to be using a feature of that which IDEA simply had no way of implementing.

This resulted in a project which I could edit reasonably easily in IDEA, but which had to be built at the command line with gradle itself. If I attempted to build and run the project inside IDEA, the code simply wouldn't work. Since I had picked up this project on a whim, I'm sorry to say that I simply put it back down again, stepped away from the directory, and I doubt I'll be going back to it any time soon. I can work around IDEA's inability to handle the feature I was using; but it'll be awkward and I am too annoyed at a pair of supposedly integrated tools entirely failing to do-the-right-thing. Sadly turing-complete build systems are intrinsically hard to reproduce without simply using the build system itself.

The message I'm hoping you will take away from this little cautionary tale is that just because you're following what you think might be best practice and using tools which purport to function well together and support one another, you may find yourself hitting a brick wall within moments of wanting to actually produce some software. I expect I'll get back to this project of mine at some point, and so perhaps also take away that it's okay to walk away from something which annoys you, and you can always come back to it later, especially if you remembered to commit it and push it to your Git server.