Java - are we worrying about the wrong things?

As I come across blogs and articles online, I invariably hit upon people debating and arguing over various topics in Java and Software engineering. At first glance one would believe, based on the often heated debate and ensuing comments, that the issues in play are very important, but in this blog entry I'll try to elucidate that, for each of these "hot topics" there is a related topic that I think is even more important but getting no press.

NOT SO IMPORTANT: Debates on Indentation style and tabs
IMPORTANT: Automated code style checkers
Whatever your chosen style is, enforce it! There are so many other issues more important to quality code (e.g. checking input arguments, proper exception handling) and code checkers like FindBugs, Checkstyle, PMD and Hammurapi can help

NOT SO IMPORTANT: Debates on why Ruby/Python/XYZ is better than Java
IMPORTANT: Writing better Unit Tests
The key is not so much about getting functionality written faster as getting fewer bugs in what you write - typical enterprise software spends much more time in testing, bug-fixing and especially in maintenance than it does in the traditional "development" phase.

Use whichever programming language you like best but I think we can all learn to test more and test better! Writing good unit tests is often harder than writing the code itself but they're just as important (some would say more so)

NOT SO IMPORTANT: Debates on why Waterfall / RUP / CMM sucks and XP/SCRUM/Crystal etc. rules (too many URLs to list)
IMPORTANT: Remember the flow is Requirements -> Design -> Develop -> Test -> Release

You can't code what's not designed - you may be designing on the fly in XP but you've still designed in your head before you've touched the keyboard (so design has to come before development).
You can't design when you don't know what to build (requirements comes before design).
You can't realistically release a product without system and user testing.

Let's focus on getting better requirements, doing better designs, doing more testing
and better development within whatever methodology we choose.

NOT SO IMPORTANT: Web 2.0
IMPORTANT: Giving users a good, solid user experience. Web 2.0 doesn't make sites better by itself - it provides powerful technologies but it's no silver bullet. There are so many terrible web sites out there with issues such as
- Too much content / too cluttered http://jdj.sys-con.com/
- Too heavy for the many folks still on dial-up
- Inconsistent labeling- etc. (See Jakob Nielsen's site for some great articles )
Sometimes you have to wonder if some web site designers actually care about their intended audience?

NOT SO IMPORTANT: The hype around SOA/ESB/JBI
IMPORTANT: Duplicate data and keeping it in synch
SOA and ESB helps you hide duplicate data and, face it, duplicate data abounds in most enterprises with more than 100 people. But how to manage it? I'm still waiting to see a reasonable industry standard approach.

NOT SO IMPORTANT: The debate on REST vs SOAP
IMPORTANT: Making the creation and parsing of XML documents faster and easier. I really don't care about the protocol beyond a certain point - as long as I've got XML going back and forth the time to
- create XML documents
- parse XML documents
- map XML to objects
is still a bottleneck.

NOT SO IMPORTANT: Choosing ORM - Hibernate vs. iBatis vs. Toplink
IMPORTANT: Good solid database table design based on expected usage patterns i.e. do we normalize or not? Are we a mostly-read app (more indexes!) or mostly-write (less indexes!).
If there's a lot of database writes happening how can we run reports simultaneously withlocking each other?

Also Important: Alleviating the Object/Relational impedance mismatch - How to exploit the power of the modern RDBMS but still maintain an OO world? You can pivot, do calculations (MAX,MIN,SUM), filter (WHERE) and sort (ORDER BY) incredibly quickly in the database. How can we make those capabilities fit more neatly into the OO world?

Also if we perform such logic in the database we violate a tenet of N-tier philosophy which says that business logic belongs in the middle-tier so how do we resolve this? How do we use the performance / scalability of the modern RDBMS and not forgo the flexibility of the N-tier architecture and the programming efficiencies of OOP?

NOT SO IMPORTANT: *nix vs. Windows
IMPORTANT: Most programs these days aren't CPU bound or even memory bound as CPU speeds grow geometrically, memory access (bus) speed grows fairly quickly too but disk speed grows soooooo slowly in comparison.

Also why can't computers be "instant-on" and boot from some ROM/Flash drive? Of course with Vista it would have to be a 1 GB drive :-)

NOT SO IMPORTANT: Hey Java JDK 5, 6 and 7 are too big or too complex or the JCP is too slow (thus the JDK too small)

IMPORTANT: Fixing critical bugs (e.g. see this) in Sun's JRE for 1.4 or 5. Don't force people to upgrade to a version (JDK 6) just out of beta to get a fix/patch for a fundamental issue!
We've open sourced JDK 6+ so why not roll that back to past JDKs (1.3, 1.4 and 5) so people can get the patches they need without the risk of new bugs from a new JVM with it's own new issues.

NOT SO IMPORTANT: We need closures in Java
IMPORTANT: Make what we have to do now (and do repeatedly) easier.

We need to support implicit caching of objects (use an "@cache " annotation?) -- just how many times do I have to write code with HashMaps to cache data in my Facades / DAOs to achieve adequate performance (and also write code for some event clear the cache)?

How do we get implicit clustering across JVMs (like Terracotta but built-in to the JVM) to keep caches in synch?

Also making JMX easier to integrate with (use an "@managed " annotation?)

A great example of JSRs already making our lives much easier is Java Generics- I love using Generics in Java 5 - and I hate when I have to go back and use 1.4 and start writing Iterator & casting "boilerplate" code again - blah! Also JDBC 3.0 making PreparedStatements implicitly cached. We need more of this work to remove the burden from developers!

They could build in better resource-leak prevention and detection support into the JDBC drivers?
"Hey Mr. Garbage Collector - look the Connection / Statement / ResultSet object is out of scope - (even if it is backed up by a real connection etc.) so clearly I don't intend to keep it around so just release it already! "

Why can't application security (authentication, authorization and cryptography) be like creating a "Decorator" around an object. Why can't we just "wrap" our application in some easy-to-specify "construct" that works for most applications (things like this never work for everyone). That would be really awesome - talk about true separation of concerns (the functionality implemented vs. who can access it and what can they do?)

Why isn't a default JMS implementation bundled with the JDK? (Perhaps as a download option to try to keep the ever bloated JDK somewhat reasonable for basic users)

NOT SO IMPORTANT: Struts vs. JSF vs. Shale
IMPORTANT: Ease the burden on all presentation-tier development
(Admittedly I know a lot more about Struts than JSF / Shale so some of this stuff may already be in JSF/Shale)

Build-in easier support for HTTP parameter checking (prevent SQL injection) on both the client-side and server-side.
Ease the burden to map from beans / value-objects to HTML grids / tables (with built-in support for sorting, filtering etc.)

NOT SO IMPORTANT: "The sky is falling" articles e.g. the now famous "IT doesn't matter" article from Harvard Business Review or things like Offshoring / outsourcing
IMPORTANT: Getting our Computer Science professors together to discuss how to give our future CS grads more relevant skills.

Perhaps create two tracks in CS? For the first two years the tracks are together as both learn basics of programming, operating systems, databases and hardware, as well math and statistics knowledge (all of which serve you over a lifetime and will always be useful) then for the last two years there's a "Computer Science" / "Software Engineering" split.

The "Scientists" can get into AI, compilers, electronics, advanced math etc. the "Engineers" get several 6-12 week internships into companies to work with real teams and learn about important things such as managing user expectations, how to interview users / stakeholders to get good requirements, how to manage project dependencies and key project risks. They learn how to maintain and work with legacy code etc.

Let's acknowledge the "Science" in Computer Science as well as the "Craft" within Software engineering.

CONCLUSION:
Now I'm sure I'll get flamed on saying a lot of these things are "NOT SO IMPORTANT" - remember I did say it was IMO :-)

But as developers and architects we end up spending so much time debating relatively unimportant things rather than focusing our time and energy on making what we already do better and faster.

For example, pro-Windows folks won't convince the hardened pro-*nix camp to switch and vice versa - but both camps could gain from improvements in the speed of disk access.
The REST and SOAP camps battle it out but also face the same performance bottlenecks (the bulkiness of XML).

These debates are often, as Macbeth said, "full of sound and fury, signifying nothing". Each side makes valid points but that's all. Many of us software engineers are true engineers at heart and need to get back to solving practical everyday problems.

We need to identify and *OWN* the bottlenecks to progress we face on an ongoing basis, and rather than engage in never-ending argument and debate (which never convinces the other side it just makes them entrench) look for synergies that will make all our lives easier.