I've heard about the same "ineffective and obstructive abstraction layers" in Java too and worked with the C++ code base where some development managers introduced such things, because "they're the managers, the must design with abstractions, the underlings can think about the details, and ho-ho, we certainly shouldn't be bothered to make something effective, don't prematurely optimize, everybody knows that, ha!"

So I consider it the effect of the"culture," "environment" and "organization" more than the particular language. It didn't help that the "patterns" were introduced exactly as the unstated promise to the managers to give them a "meta" approach. Like UML before etc. And that people started to think the more abstractions they force in the code, the better it becomes.

My favorite problem description is by Rico Mariani:

"The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time."

http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance...

But in my opinion all big enough projects can be saved by redoing just some part of them.

The word "optimisation" should not be confused with considering computational complexity, and I believe we are in dire need for a catchy word for the latter.

One of the most important steps in programming is:

How many elements could this code actually have to process, and if there could be many: is this datastructure/algorithm suitable for that?

This is almost never premature. This should NOT be called optimisation.

I would like an own word for that. Suggestions?

Yes you should always think about optimisation, even if you never end up coding for it. Every function I write I think about what is the effect that it will have on the rest of the code and what will I need to change if it later turns out to be a bottle neck. The advantage of this is I sometimes avoid writing some dumb code - even if it never matters from a performance perspective I have thought a little bit more deeply about what I want to accomplish.

To answer your question how does thinkthencode sound?

I think the operative word is "premature". If you actually have a reasonable idea of how much data you're going to be working with, it's not premature at that point to put some time into optimization.

Also, I would restate the rule as something like "don't spend too much time prematurely optimizing. If you're building a lookup, it's obviously a Good Thing to use a hash instead of a linked list, and in 99% of cases shouldn't take you any longer to code.

While not particularly original, I would place this under 'thoughtfulness' / 'thoughtfully'. Code thoughtfully, but don't dive into premature optimization.

design

For the former, I always preferred Joe Armstrong's quote in Erlang and OTP in Action. “Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”

It's the same idea as the Knuth quote, but gives you guidance over what to optimize for (rather than just leaving you with the idea you shouldn't optimize for anything). Beautiful code will oftentimes include an elegant, efficient algorithm. Many times I've found that when I've had a performance bottleneck, the fix also made the code more correct (not just on a performance standard, but things like "Oh...yeah, we totally didn't need that there" or "tweaking that to be faster also meant we just fixed a possible, if unlikely, race condition"), or more beautiful ("oh, we just removed a duplication of effort...that when called this way was turning an O(N) operation into an O(N^2) operation"); had I just adhered more stringently to those two, I would have had the performance already.

> Another far more common antipattern that isn't mentioned here is premature abstraction. You see a lot of this in enterprise .NET codebases -- such as the widespread "best practice" to build ineffective and obstructive abstraction layers "just in case you might want to swap out Entity Framework for a web service."

And Java codebases

Where I get twitchy is the practice of coding has changed a lot since Knuth made that quote. Optimizing code in that era typically made it brittle and hard to reason about. Pre-optimizing meant continuously painting yourself in a corner. I used to think about it as like a seamstress sewing a dress, she doesn't start out sewing nice neat tight stitches, that's for later. Once she knows she's not going to have to rip the seams apart again.

Some optimizations don't matter anymore. Back in the hoary old days pointers in C were faster than indexed arrays. Not anymore. But people still assume it's worth it. Twenty years ago, you paid a serious price for unaligned accesses. Not any more. Yet compilers still rigorously align data in memory. Which might actually make things slower.

As the follow on poster said, make the code clean and easy to reason about. People often like to think they are writing code like the big boys, where it'll get used by vast number of people. Much like a lot of hardware designers design stuff as if they are going to make millions of units. 99% of the time that's not true. Thus the NRE costs totally dominate.

Yeah, I also found that making educated guesses about optimization spots early is important. You cannot not optimize all the time. Overspending resources on optimization happens because the team is not working together well or the developers aren't experienced enough. This can't be changed with a quote though. It needs time, training and good guidance by the management.

> Another far more common antipattern that isn't mentioned here is premature abstraction

He does address this one in point 9:

Useless (Poltergeist) Classes Useless classes with no real responsibility of their own, often used to just invoke methods in another class or add an unneeded layer of abstraction.

Over-abstraction is extremely common in 'Enterprise' Java codebases too.

"No need to worry about optimisation, modern compilers can handle that for you." /s

At least it was correctly quoted in this article, which it frequently isn't.

>While the points the author makes are valid, the fact that it gets bandied about as an out-of-context sound bite results in a lot of code getting written with a complete disregard for any optimisation whatsoever.

This is still preferable to premature optimization.

What I really can't stand is developers who tell me that this piece of code that already runs in production with no complaints is 'slow'.

And I ask them "well, did you profile it?".

"Well, no, but..."

I think the article is taking it to mean what we want it to: don't write obtuse/opaque code just because you think that the straightforward way to do it, relevant language feature, natural abstraction, etc. is "too slow."

Find out whether sacrificing clarity for speed is even categorically worth it in this particular function, and find out whether your alleged speed improvement is proportional to its readability costs.

Instead of inserting abstraction layers, just design to interfaces instead.