Yeah, I'd have to say I'm with you on this one. I once failed an interview because the interviewer wanted me to say that java Strings are immutable, and it's been maybe 10 years since I consciously thought about it. Hell, the times it really made sense to use a StringBuffer or a StringBuilder instead of using simple String concatenation have been few and far between.

The types of performance issues I see are attributable to architecture and design, such as 1) code so complex it retrieves the same large dataset 39 times during initialization of the app; 2) Deep data fetches to populate 25 backing views for a list of items being displayed, because someone decided it was more 'performant' to populate large data structures and UI objects for when that when the user selected something from the list, the associated detail view would pop up immediately. Never mind how long it took the list to display. 3) designing a data model to optimize the production of XML transport data, rather than modeling entities of the business domain and treating serialization of that data as a byproduct, rather than the product itself.

Stupid, stupid things kids worry about. And if you don't think I know anything about writing Java code, you can download and run this.

Too true, too true.

I think back to all those high school pep rallies and see them now as a form of brainwashing. Why were we cheering for the jocks and pretty prom princesses? What have they done for the rest of us?

You are humor impaired, Mr. Booger.

Everyone knows that newts are smarter.

That's DataSAAB Interpretive Language / DataSAAB Assember Language. Back in the days of minicomputers with magnetic core, punchcards, paper tape readers, and hard disk drives the size of washing machines.

Sounds like you and I were on the same project! But then, every Boeing software project sounds like what you described.

As stated in the animation: 'pecisely twisted'. Makes me wonder.

It's not only optimizations that an immature software process will get bogged down in (optimization increases complexity, for sure); but the tendency to be enamoured by the current fad development stack (as noted in the article) because it will somehow magically make all the cruft built into their current stack go away. It's like calling 'do-overs' instead of going back and working in the small to make incremental simplifications of process, configuration, data models, and api. That's just too unsexy for most young developers, but we mature guys know that new tools != better outcome.

I thought they said you was dead...