4 ms·

The author mentions that changing tested code decreases its value. The steepness of this curve varies greatly depending on the language. The strong guarantees o

• silentbicycle 18y ago
  The type systems in Haskell, OCaml, etc. fit the author's requirements for automated testing. Once you have enough experience to trust them when they check whether local changes are still globally correct, making bold changes to clean things up stops feeling reckless. (Automated testing suites are still helpful, but the type system writes/adapts many of the test cases for you.) But what I find more alarming, is that the author completely misses the human side from the perspective of programmers: a good programmer that is forbidden from changing ugly code will become frustrated and will either become less productive or leave. YES. The inevitable pain and misery in maintaining a really huge, ill-factored codebase can scare good developers away. While solving hard technical problems is often intrinsically rewarding for hackers, solving problems largely caused by disorganization is just a sigh of relief at best.
  • Tamerlin 18y ago
    "solving problems largely caused by disorganization is just a sigh of relief at best." In most cases, it's a source of attrition and a waste of talent, because finding time to actually FIX it is such a huge task that no one has time for it, and good developers won't want to spend their time stagnating long enough to learn the ins and outs of the spaghetti code to be able to implement incremental fixes.
    • silentbicycle 18y ago
      A core of ugly code perpetuates itself. Partially due to social causes, partially due to the sheer inertia. Sad but true.
• briansmith 18y ago
  "The strong guarantees of a language like Haskell mitigates the risk and so ensures a less dramatic drop." Haskell's strong typing may help prevent some bugs, but Haskell's evaluation model means that even a slight change (literally one character) can change the performance characteristics of your program, in space and time, by orders of magnitude. Because of that, I've found that Haskell programs require more testing than Python programs, to ensure there are no edge cases that have space leaks. I am a fan of Haskell for some classes of programs (like compilers and inference systems) where you can spend a lot of time perfecting a strongly-typed data model that is fairly unchanging--one where "Big Design Up Front" makes sense. But, I cannot say that Haskell's strong typing is always a net plus when the data model needs to be frequently updated. In Haskell you often have to write extra code, or code that is more abstract in order to get programs to typecheck. Then, you still have to write almost the same kinds of unit tests that you would have to write if you were using any other language. With Python or Ruby you can skip the type system workarounds, which often means you have less code to deploy. I am a big believer that less code == better code. Dealing with ugly code is part of being a good developer. I believe you should leave ugly code around until you need to change it. When you need to change it, you can rewrite it to make it more beautiful, but only if that beautification facilitates the improvement you were originally tasked with making. But, it is usually a bad idea to go around tidying up code for the sake of tidiness. Also, think about this: if the original code is really unclear, then what confidence do you have that you understand it well enough to rewrite it correctly; if the code is clear enough to be easily rewritten, then why does it need to be changed?
  • wynand 18y ago
    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.
• edw519 18y ago
  a good programmer that is forbidden from changing ugly code will become frustrated and will either become less productive or leave Absolutely. Only so many bandaids can cover the Grand Canyon. Sometimes, you just gotta bite the bullet and make it right. It's extremely frustrating leaving a mess in your wake, regardless of source.