

 Is it OK to replace optimized code with readable code? - hansbo
http://arstechnica.com/information-technology/2012/08/is-it-ok-to-replace-optimized-code-with-readable-code/

======
MBlume
I can't believe no one's saying this.

If you're asking, then YES, DO IT.

First of all, I'll assume you're not an idiot. If you're an idiot, and your
task requires you to interact with this code, you're fucked no matter what.

So, assuming you're not an idiot, and you've _asked the question_ , means
you're already pretty damn confident this code's not on a critical path. And
what does that mean? Means some asshole was showing off how clever ey was by
prematurely optimizing, and it's already come back to bite you in the form of
difficult maintenance. So take a blowtorch to it already.

~~~
jandrewrogers
On the other hand, the reverse is true as well.

Most software engineers, smart or not, do not have the skill or experience to
even analyze the intent of highly-optimized implementations. The complexity is
obvious but the interactions being manipulated are not unless software system
optimization is a domain of expertise. It would be like asking me to analyze
GUI design.

I have seen many examples of smart engineers being "damn confident" that code
was over-engineered and possibly even suboptimal only to make the code
simpler, sometimes even faster, and broken. I design high-performance software
systems and am the optimization guy. There have been many cases where a smart
engineer decides that I am actually "some asshole showing off how clever ey
was" and then "fixes" my work. Which then has to be redone when the purpose of
the original implementation rematerializes.

The engineers in these cases are not idiots, they simply don't understand the
nature of the optimization or why it is happening in a particular place. There
are many cases of premature optimization but that is not always the case just
because it looks like it. If there are people around that actually understand
optimization then at least ask one of them about the code in question,
particularly if they wrote it.

~~~
quanticle
Exactly. It's too easy to break Zawinsky's first commandment (Thou shalt not
break working code) with changes like this. Sure, if the code is _getting in
the way_ of a change, then go ahead and change it. But I don't think that's
what the questioner is asking. It seems like he or she has noticed this "ugly"
code and wants to change it out of a misplaced sense of conscientiousness.

EDIT: I just remembered that something like this happened to me when I was an
intern at my first position doing "real" software development. I'd noticed a
particular piece of gnarly code and asked my team lead for permission to
refactor. He, in turn, told me that for a rarely used code path like the one I
was proposing to refactor, the costs of QA and deployment would greatly
outweigh any savings my changes would generate for the company. His concluding
words were, "Sometimes it's easier to let sleeping dogs lie," and I think
that's something that applies to this situation as well.

~~~
MBlume
First paragraph:

> Sometimes you run into a situation where you have to extend/improve some
> existing code. You see that the old code is very lean, but it's also
> difficult to extend, and takes time to read.

Last paragraph:

> Is it a good idea to change such code if you have to touch a small piece of
> it either way?

------
tlogan
99% of optimized code I saw in my life is optimized as result of process
called "performance decoration": optimizing piece of code based on some
(mainly faulty) assumptions without tests and profiling.

I think "performance decoration" is defined as a process in which you make
software to look fast but without any positive impact on actual delivered
performance (there was an article in ACM a while ago about it).

For example, I saw heavily optimized (and convoluted) C++ loops inside I/O
heavy code where just increasing block size and enabling direct IO gives 90%
performance boost.

So if there is no "performance lifecycle management" explanation related to
optimized code (i.e., which test needs to be run, what is dependency, etc.)
then the code is probably just "performance decoration". My theory is: if
somebody did investigation to show that this is a valid performance
optimization he would probably document all needed tests which led him/her to
that conclusion.

~~~
solutionyogi
I love this term 'Performance Decoration' and I am going to steal it!
Perfectly describes some of the code I have seen in my career.

~~~
tlogan
The term was coined by Bart Smaalders in his article “Performance Anti-
Patterns”, ACM Queue, Vol. 4, No. 1, February 2006.

------
rbanffy
I always optimize new code for readability. If the old code is on a hot path,
I'd suggest adding comments explaining why did it end like it did and leaving
it alone (unless you readable version is equally fast). If it's not and it's
structure starts to interfere with maintenance, replace it with simpler code.

Of course, before you touch it, make sure it's adequately tested and, if not,
make it adequately tested.

------
njharman
If you ask this question, then no. Otherwise, you know the answer.

Further explanation on #1 You lack the experience required to understand the
ramifications, make the judgement, change the code. Gain experience, learn
more about this codebase and you will "know" one day.

Given that, one of the "best" ways to gain experience is to make and suffer
through recovering from mistakes, change away!

------
calinet6
I was going to write a detailed explanation of the trade-offs and cases where
you might want to make such a change, but turns out, the article did an
_excellent_ job of hitting that question from all conceivable sides. Really
quite good.

~~~
klodolph
Well, naturally. It was originally a popular question on
programmers.stackexchange.com, so the answers got a lot of eyes and a lot of
editors.

[http://programmers.stackexchange.com/questions/152392/is-
it-...](http://programmers.stackexchange.com/questions/152392/is-it-ok-to-
replace-optimized-code-with-readable-code)

That covers all the cases, then the second half of the article goes into more
depth on the underlying reasons. It's a nice formula for an article.

~~~
Groxx
There's a second half of the article? All I see are the top 3 answers copy &
pasted into a blog post.

------
steve8918
It depends.

Are you touching the code because you need to fix a bug in it? If so, then
yes.

If you need to maintain this piece of code then you might as well fix it to
the best of your ability and knowledge, but please be careful.

Are you touching the code because you came across it, and you don't like how
it looks? If so, then no.

It's a shame that unreadable code exists, but you can't save the world. My mom
used to tell me "Don't sit in someone else's pile of shit." Meaning, if
someone else made a mess, and if you're the last person to touch it, you're
going to look like the one who did it. There are bigger fish to fry in any
software project than shitty-code-that-hasn't-been-touched-in-a-while-that-
works.

------
Zenst
You realy have to ask why it was optimized in the first place. Now if that
optimization has been negated by the enviroment then you can ask yourself the
next question. Does the code need to be or envisaged in the near future to
need changing for a reason other than making something that works into
something that works and is readable but not as fast.

Both question are important and if you answear no to either then your best
leaving the change to a time when you have to change it. Reason being that you
may have a margin in the enviroment negating the optimization today, but that
may change before you need to change the code for a reason of business. You
could end up beutifying it and losing that optimization and then end up
hitting that wall a few months/years down the line and have to reinvent that
optimization.

Over all the most important aspect about reading code is to understand the
structure and by that this part does this and that part does that. If your
calling a optimized load of code in a function then if that code is sexy
looking or not it will still have the same look from anything that calls it.

So as a rule, if you don't have to touch it and don't need to touch it then
ask yourself why your touching it and are you workbombing yourself with
something in a less busy period that will drag on over into a busy period and
cause you regret it down the line. Also make sure your doing it for the right
reasons, beyond putting a flag ontop of a mountain so to speak, what are you
gaining. If something works and does not need to change then changing it just
to make it pretty is like arguing all programmers should be wearing size 0
dress's to many peoples minds.

------
thibaut_barrere
It's a trade-off between optimization for speed of machines and optimization
for speed and ability of humans who need to maintain the code over time.

If it has been prematurely optimized for speed, by all mean yes :)

------
tsotha
As the first answer on ars says, it depends. If it doesn't need to be
optimized for speed it should be optimized for maintainability.

------
blucz
The best thing is to replace the unreadable code with readable code while
preserving or improving its performance characteristics.

Optimized code is often unreadable because the initial implementation didn't
forsee the future optimization. A re-write that takes both into account at
once is usually at least as fast and much more readable.

------
jakejake
Over and over again in my career I run into scenarios where code maintenance
is the biggest challenge. Only occasionally do I run into issues with code
performance. But, I mainly work on business type apps. If I were doing real-
time or embedded systems with limited resources I'm sure my experiences would
be totally different.

~~~
colomon
I've had to optimize code because it ran too slowly on a Cray supercomputer.

Mind you, I think my optimized version may have been a bit clearer than the
original, though more mathy.

------
davvid
Is it broken? No? Why are you touching it? Because you didn't write it? Please
get off my lawn! ;-)

------
jph
Communicate: ask your team to find out who wrote it, and why. Ideally you're
using git and can use git blame to find the author. Benchmark the difference,
because maybe there's more going on that you expect at first.

------
davtbaum
Who ever said optimization and readability were mutually exclusive?

If the engineer who develops this (provably optimized) codebase can't read the
code, he/she should be replaced with someone who can.

~~~
Rastafarian
Right, an advice with zero practical value. There's such an abundance of great
programmers awaiting a job/contract offer ...

------
EvaPeron
No. assholes. ever.

------
rorrr
Arstechnica should be banned for submitting these spammy articles. The content
is clearly ripped off from

[http://programmers.stackexchange.com/questions/152392/is-
it-...](http://programmers.stackexchange.com/questions/152392/is-it-ok-to-
replace-optimized-code-with-readable-code)

~~~
nitrogen
From the article: _This Q &A is part of a biweekly series of posts
highlighting common questions encountered by technophiles and answered by
users at Stack Exchange, a free, community-powered network of 80+ Q&A sites._

It's not as if they're trying to hide the source, and the content is presented
in an easier to read format than SE. The only question one might ask is why
most of hansbo's submissions are for arstechnica.com articles.

