on Software

Follow me on GitHub

The Nature Of Java Application Development

20 Nov 2018

Building things in Java has many great benefits.

Many programmers experience them all the time. Me included. The language gives you an awesomely rich experience, and the ecosystem makes you get stuff done efficiently.

Take refactorings like a simple Method rename. It happens all the time. In Eclipse it’s Alt+Shift+R and you’re done. A no-brainer. In other languages this could be a considerable effort. That advantage materialises only though, when all your code is in one location. So that is what you do. A big project in your IDE with everything in it. Yes you can! Millions of lines of code at your fingers. Never any worries, because your IDE can get you out of complicated situations at all times. Sounds good. I like it too, and this is how it’s got to be done to be efficient.

  • You don’t need to think about interfaces between your software components. At runtime all classes live in one classloader. Big lump. No separation.
  • You don’t need to think about architecture. The architecture of a typical JEE application is predetermined. So far so good, but this non-architecture - or shall we call it orderlyness - can easily strech out to business code as well, because you start small and hack in whatever the requirement of the day is.
  • No need to think about documentation, because the source code is all you need. It costs time and would be wrong anyway.

I am certain you can run a business off of that. Hire cheap devs, churn out code quickly, have quick development cycles, get requirements out the door at pace.

My argument is, that this does not scale. But eventually you’ll want your business to.

  • Above is pointed out what you don’t have to think about. We all know that thinking is the hardest thing to do. So consequently your dev team just doesn’t care much for the debt in their backyard. Discipline strictly not needed. Average performance plus Java tooling is good enough to make money. But wait, did you not set out to beat them?
  • According to Conway’s Law, a big lump of coders is what you’ll end up with. This is the antithesis to scalability, neither in software nor organisational.
  • There will eventually be a need to integrate with the outside world. May that be the filesystem, an email server or some esoteric external system. Most times there is an urgent business need, oftentimes tremendous business value in integration. Unfortunately the IDE-tooling-indulged-devs just don’t know how to do that. Suddenly it’s all about interfaces, documentation and syncronisation and error handling, and how did that resource adapter thingy work again?
  • Your productivity level is as high as it is, as long as you can stay in that world of yours. The skillset needed to reliably interface your software to the world, or with itself, is considerably different to what you got sitting in your office.
  • Scaling and extending your product is all about being clear where what runs, what and how to factor out, modularise, parallelise and what pieces are talking to what other pieces. With your one-lump application, you just lost. Time to throw it away and start afresh with scalability in mind. I think that’s a valid business approach, because your one-lump-app may well be technically outdated. Easy. But wait, your one-lump-application devs don’t know how to make an structured app that scales because they never had to do anything alike.

The way out would of course be to organise and structure your dev team and their yield from day one, and make sure they have the skills needed to grow your product and your organisation.