on Software

The Nature Of Java Application Development

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.