My Haskell experience is too limited for me to have experienced performance changes resulting from small code changes. OCaml has a fairly predictable performanc

My Haskell experience is too limited for me to have experienced performance changes resulting from small code changes. OCaml has a fairly predictable performance model and a language which combines aspects from OCaml and Haskell (this is the point where someone shouts "Scala!") will go a long way to reduce brittleness in the code and won't require much testing for unexpected performance issues. I thought more about the original article yesterday and realized that - regardless of the language one uses - the author made a mistake by implying that the quality peak is equally high as one moves to the right of the graph. If by "beautiful code" we mean well designed code, then changes will have far less far-reaching effects. The quality peak will be lower (relative to the graph) and hence the descent induced by changes, less steep. And this happens because as you rightly state, less code == better code. If a company needs to be agile (in the general sense of the word), their software should also be easy enough to adapt to changing circumstances. Given that good code allows for such changes, the extra effort to produce good code pays for itself. On the other hand, for a piece of software that is at the end of its lifetime, there is little of sweeping changes. Beautification of end-of-life code is a bad use of time. You are right that a programmer should be willing to endure some ugly code. Anything which encodes real world relationships (which are complex and messy) will have some ugliness in it. A programmer which rails against this makes life difficult for everyone around. But this can be taken too far and I have known people that are too conservative in this regard; this made the software unnecessarily hard to maintain and the programmers unhappy [1]. The answer to your last statement is that if you have to modify barely understandable code, then it is worth refactoring (and as a last resort, rewriting) it, even if you don't understand every aspect of it. If you don't you will likely spend more time trying to paste your code in somewhere in the hope that it will work and in so doing you the crufty monster will get even bigger and harder to maintain (and you don't gain an understanding of the code which is a very valuable asset to the owners of the code). [1] No company has a legal obligation to keep employees happy. But such companies can expect mediocrity if they're lucky but probably much less. Edit: I obviously don't know HN's markup. Fixed italization.