Maintainable Code or High Productivity?

Latest Java Update: Maintainable Code or High Productivity?

picture of a java window

I have been doing a little development lately in addition to my routine task. Something that’s struck me: checking a one-line code repair requires some minutes.

Development goes in stages between maintainable and productive, typically hitting among those extremes at the same time.

The art of programs moves rapidly. Some people have taken part in Rapid Application Development (RAD), where making a modification and getting it to production happens from an IDE (or not) and takes seconds. On the other hand, we’ve all seen catastrophic production interruptions, when some developer pushes a product to production that should not exist.

In other situations we’ve done extremely maintainable development where nothing is a one-line code change and releasing what would be a one-line code modification to production is an act of sheer will with a lot of moving pieces. The software world likes to do this and makes intricacy extremely well, thank you quite.

Take a historical example of RAD. In the Java world, JBuilder utilized to be able to release to Weblogic incrementally. In the PHP world, you could modify a file on the web server or locally, then SCP it into the ideal directory. In any case, you could quickly check that file locally. In the Microsoft world, back in the VB days, you could easily make a modification, then struck Run and test it once again. Microsoft still leads in the cloud era with the auto swap, however, let’s admit it, it ain’t like it used to be.

Take the greatest historical example of software application development. Java EE abstracted you from the hardware and, in exchange, needed you to create about 20 embedded Zip files (OK, a small exaggeration) and 15 different XML descriptors (not an exaggeration in a considerable app) to check a one-line code modification in your Design 2 controller. On the one hand: Look ma, say goodbye to someone-did-something-by-mistake in production! And say goodbye to buffer under/overruns. On the contrary: it was a productivity suck.

Fast-forward to today, as well as the language efficiency for a full stack application, is an intriguing performance suck. Adding a small detail in a Java servlet or C# app is nothing compared to an entirely practical shows monster. No more will you pull a header from an injected environment thing, oh no, we need to determine how to do this in an entirely stateless manner that stays “functional” throughout.

Additionally, take a look at Docker. I enjoy Docker. Had Sun Microsystems decided to stick product packaging in with Solaris Zones/Containers, then perhaps Sun would’ve totally recovered from the dot-com bomb and acquired Oracle instead of the other way around.

When Docker is a vital part of your develop procedure, you have a lighter-weight variation of the Java EE product packaging issue. To make a modification, I have to build the change, reduce the container, restore the tank, and raise the container. There is no incremental anything.

For now, enjoy waiting minutes to check an incredibly small modification even in your area while production remains stable. We reside in interesting– however maintainable– times.

This story, “Select one: High efficiency or code you can maintain” was initially published by InfoWorld.

To find out what JAVA is all about, watch this video on how to find out about Maintainable Code:

No response yet on Maintainable Code or High Productivity?

Leave a comment

will not be published