5 ms·

I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joel

I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html From the article: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive." EDIT: Joel isn't actually recommending "do nothing" - on the contrary - the article goes into some depth on ways one can improve software without throwing everything away and starting from scratch.

geofft 11y ago
And your old code doesn't have a test suite you can run on the new code? Well there's your problem. Testless code doesn't acquire bugs by just sitting around on your hard drive, but it doesn't lose any bugs that way, either, and without a test suite you can't afford to do anything but leave it sitting around.
- chadgeidel 11y ago
  You are correct, of course - but back in the old days that this article was written unit testing wasn't as widely adopted as it was today. Joel does recommend solutions to improving code, and I'll bet if he wrote that article today he would include unit testing as a part of the solution.
- pjmlp 11y ago
  Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as
  - the_af 11y ago
    I find it odd how many people overlook this fact. I think people reading tech blogs and sites sometimes live in a bubble. I don't know if in most, but in many companies there are no automated tests at all, and very few "best practices" such as automated builds/continuous integration and even decent source control. I don't want to name names, but I'll say this: I know for a fact at least one IT/support department in the local branch of a HUGE multinational energy company (guess a few names and you'll get it) doesn't do automated tests of any kind. They are similarly clueless about most things tech-minded folk would consider best practices of the last decade. This department doesn't work on core software, but instead on inventory/procurement systems, but still...
  - acqq 11y ago
    It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.
  - Retric 11y ago
    One of my favorite quotes when QA ‘let’ an obvious bug into production was: “We stopped testing his code five years ago.” You can take this in many ways, but in the end getting the right amount of testing is a really hard Cost / Benefit problem and there is no one size fit’s all solution. PS: From the same dev, "I don't trust QA." and "TDD/Code contracts/etc. sounds nice, but knowing what the output should be is really the hard part and tests don't help you with that."
  - EGreg 11y ago
    Should have unit tested that comment
  - dlitz 11y ago
    Something like 60% of enterprise IT projects are considered failures, too. If you don't write tests, then you're throwing away your investment. It's that simple. Telling me that the code works today tells me nothing about how much value the code will add to the business in the next year. Sooner or later, you won't be able to predict whether a 'small' task will take 3 weeks or 3 years. Even if you don't change the software, some integer overflow might abruptly halt everything. ("It's the primary key for everything? And we don't have tests? Oh...") Anyone can write code, but it's usually high-risk code with lots of hidden costs. The value that career software developers bring to the table is the ability to manage the software development process so that it's more-or-less sustainable, i.e. keeping costs visible and managing risk so that the resulting software retains its value over time. If your publicly-traded company depends heavily on software that isn't properly tested, then ethically this should be listed as a risk factor in your 10-K forms. Sooner or later, shareholders are going to figure this out and start holding these enterprises' management accountable.
    - JupiterMoon 11y ago
      > ... should be listed as a risk factor in your 10-K forms. Sooner or later, shareholders are going to figure this out and start holding these enterprises' management accountable. And on that day publicly traded companies will start to implement comprehensive test suites. Until then they are just extra costs as far as (most) management is concerned and management loves to 'trim the fat' and eliminate costs.
- SonicSoul 11y ago
  You're assuming that old code doesn't have tests, or that tests can't be written for it, or that it can't be patched without a rewrite?
  - geofft 11y ago
    I'm assuming that if it doesn't have regression tests, the old code is untouchable / legacy code, because you can't add features to it without risking breaking something. If it does have regression tests, then you can rewrite it and only switch to the rewrite once it passes all tests. Joel's argument goes away, because the regression tests document exactly what obscure edge cases you wouldn't have thought of.
emergentcypher 11y ago
Just because it's old, and you've fixed some bugs, doesn't mean that more bugs won't be discovered in the future. Perhaps the new code is in a language or paradigm that is less prone to certain classes of bug.
justin66 11y ago
Ken Thompson: "And I've always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I've never been a lover of existing code. Code by itself almost rots and it's gotta be rewritten. Even when nothing has changed, for some reason it rots."
- brudgers 11y ago
  Thompson wrote Vi's predecessor ed. It is purported that he was a user of Rob Pike's sam editor from Plan9. http://www.catb.org/esr/writings/taoup/html/ch13s02.html http://www.catb.org/esr/writings/taoup/html/ch13s02.html
- stinos 11y ago
  McCoy: "I know engineers, they love to change things"
nkassis 11y ago
If I remember correctly Joel wasn't opposed to refactoring old code. That article seemed to be mainly against wholesale rewrites which I agree in a most cases. He is now paying the price for taking this rule to the extreme. I think sometimes rewrites are unavoidable as tech on which the old code is based dies and the current code needs to continue to be extended. In Joel's company case they slowly ended up having to write an entire compiler and language to keep their old code running. Relevant passage: "First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code."
- chadgeidel 11y ago
  Exactly - I (incorrectly) assumed most folks had previously read the article. Mea culpa.
  - zhiyuany 11y ago
    May I know which article? (I mean, the article about joel's paying the price.
    - nkassis 11y ago
      Background on Wasabi: http://www.joelonsoftware.com/items/2006/09/01b.html http://www.joelonsoftware.com/items/2006/09/01b.html http://blog.fogcreek.com/the-origin-of-wasabi/ http://blog.fogcreek.com/the-origin-of-wasabi/ Killing of wasabi: http://blog.fogcreek.com/killing-off-wasabi-part-1/ http://blog.fogcreek.com/killing-off-wasabi-part-1/ Codding Horror on Wasabi: http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha...
stinos 11y ago
It doesn't acquire bugs just by sitting around on your hard drive. Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require a complete rewrite, just that it's not because code has been fine for 10years that it is bugfree and needs no more work ever. (though in cases like this switching to a proven lib for handling key input if such a thing even exist might be a solution - which then introduces new problems like more dependencies and bugs in that lib making your own software not working properly and so on and so on:)
- brudgers 11y ago
  There are also latent bugs which are inconceivable at design time and only become possible after several cycles of Moore's law. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html?m=1 http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
  - knodi123 11y ago
    I remember I once went to great trouble to use a succession of old computers to copy my favorite DOS game off of a 5 1/4" floppy into a 3 1/2" floppy, and then from there onto a network, and then onto my laptop, so I could take it to school with me. And in the end, I learned that the game ran so fast on my laptop that your character would move at light speed and then die as soon as you pressed a button, because my laptop was too fast. There was nothing wrong with the program, it just didn't expect to still be in use 17 years later.
    - im3w1l 11y ago
      If you still want to play it, dosbox supports adjusting emulation speed.
      - knodi123 11y ago
magicmu 11y ago
Absolutely. As a vim user, one of my favorite things about it is how it is on virtually every platform -- it's similar to what the article says about Netscape. Is the code pretty? Probably not. But I would rather have my text editor be compatible with any OS I may need to use it on than it have a readable codebase.
jayvanguard 11y ago
> It doesn't acquire bugs just by sitting around on your hard drive. Wrong. There are entire classes of bugs that have to do with adapting to new environments, security standards, etc.
bjourne 11y ago
He is talking about commercial software where the only thing that counts is money in and money out. That a free software developer should never clone and rewrite another developers software is false. Lots of successful projects are rewrites or clones of existing software, like QMail over Sendmail and vim itself over vi.
- carussell 11y ago
  Er, the article in question was written about Mozilla...

geofft 11y ago

And your old code doesn't have a test suite you can run on the new code? Well there's your problem. Testless code doesn't acquire bugs by just sitting around on your hard drive, but it doesn't lose any bugs that way, either, and without a test suite you can't afford to do anything but leave it sitting around.

chadgeidel 11y ago
You are correct, of course - but back in the old days that this article was written unit testing wasn't as widely adopted as it was today. Joel does recommend solutions to improving code, and I'll bet if he wrote that article today he would include unit testing as a part of the solution.
pjmlp 11y ago
Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as
- the_af 11y ago
  I find it odd how many people overlook this fact. I think people reading tech blogs and sites sometimes live in a bubble. I don't know if in most, but in many companies there are no automated tests at all, and very few "best practices" such as automated builds/continuous integration and even decent source control. I don't want to name names, but I'll say this: I know for a fact at least one IT/support department in the local branch of a HUGE multinational energy company (guess a few names and you'll get it) doesn't do automated tests of any kind. They are similarly clueless about most things tech-minded folk would consider best practices of the last decade. This department doesn't work on core software, but instead on inventory/procurement systems, but still...
- acqq 11y ago
  It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.
- Retric 11y ago
  One of my favorite quotes when QA ‘let’ an obvious bug into production was: “We stopped testing his code five years ago.” You can take this in many ways, but in the end getting the right amount of testing is a really hard Cost / Benefit problem and there is no one size fit’s all solution. PS: From the same dev, "I don't trust QA." and "TDD/Code contracts/etc. sounds nice, but knowing what the output should be is really the hard part and tests don't help you with that."
- EGreg 11y ago
  Should have unit tested that comment
- dlitz 11y ago
  Something like 60% of enterprise IT projects are considered failures, too. If you don't write tests, then you're throwing away your investment. It's that simple. Telling me that the code works today tells me nothing about how much value the code will add to the business in the next year. Sooner or later, you won't be able to predict whether a 'small' task will take 3 weeks or 3 years. Even if you don't change the software, some integer overflow might abruptly halt everything. ("It's the primary key for everything? And we don't have tests? Oh...") Anyone can write code, but it's usually high-risk code with lots of hidden costs. The value that career software developers bring to the table is the ability to manage the software development process so that it's more-or-less sustainable, i.e. keeping costs visible and managing risk so that the resulting software retains its value over time. If your publicly-traded company depends heavily on software that isn't properly tested, then ethically this should be listed as a risk factor in your 10-K forms. Sooner or later, shareholders are going to figure this out and start holding these enterprises' management accountable.
  - JupiterMoon 11y ago
    > ... should be listed as a risk factor in your 10-K forms. Sooner or later, shareholders are going to figure this out and start holding these enterprises' management accountable. And on that day publicly traded companies will start to implement comprehensive test suites. Until then they are just extra costs as far as (most) management is concerned and management loves to 'trim the fat' and eliminate costs.
SonicSoul 11y ago
You're assuming that old code doesn't have tests, or that tests can't be written for it, or that it can't be patched without a rewrite?
- geofft 11y ago
  I'm assuming that if it doesn't have regression tests, the old code is untouchable / legacy code, because you can't add features to it without risking breaking something. If it does have regression tests, then you can rewrite it and only switch to the rewrite once it passes all tests. Joel's argument goes away, because the regression tests document exactly what obscure edge cases you wouldn't have thought of.

emergentcypher 11y ago

Just because it's old, and you've fixed some bugs, doesn't mean that more bugs won't be discovered in the future. Perhaps the new code is in a language or paradigm that is less prone to certain classes of bug.

justin66 11y ago

Ken Thompson: "And I've always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I've never been a lover of existing code. Code by itself almost rots and it's gotta be rewritten. Even when nothing has changed, for some reason it rots."

brudgers 11y ago
Thompson wrote Vi's predecessor ed. It is purported that he was a user of Rob Pike's sam editor from Plan9. http://www.catb.org/esr/writings/taoup/html/ch13s02.html http://www.catb.org/esr/writings/taoup/html/ch13s02.html
stinos 11y ago
McCoy: "I know engineers, they love to change things"

nkassis 11y ago

If I remember correctly Joel wasn't opposed to refactoring old code. That article seemed to be mainly against wholesale rewrites which I agree in a most cases. He is now paying the price for taking this rule to the extreme. I think sometimes rewrites are unavoidable as tech on which the old code is based dies and the current code needs to continue to be extended. In Joel's company case they slowly ended up having to write an entire compiler and language to keep their old code running. Relevant passage: "First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code."

chadgeidel 11y ago
Exactly - I (incorrectly) assumed most folks had previously read the article. Mea culpa.
- zhiyuany 11y ago
  May I know which article? (I mean, the article about joel's paying the price.
  - nkassis 11y ago
    Background on Wasabi: http://www.joelonsoftware.com/items/2006/09/01b.html http://www.joelonsoftware.com/items/2006/09/01b.html http://blog.fogcreek.com/the-origin-of-wasabi/ http://blog.fogcreek.com/the-origin-of-wasabi/ Killing of wasabi: http://blog.fogcreek.com/killing-off-wasabi-part-1/ http://blog.fogcreek.com/killing-off-wasabi-part-1/ Codding Horror on Wasabi: http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha...

stinos 11y ago

It doesn't acquire bugs just by sitting around on your hard drive. Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require a complete rewrite, just that it's not because code has been fine for 10years that it is bugfree and needs no more work ever. (though in cases like this switching to a proven lib for handling key input if such a thing even exist might be a solution - which then introduces new problems like more dependencies and bugs in that lib making your own software not working properly and so on and so on:)

brudgers 11y ago
There are also latent bugs which are inconceivable at design time and only become possible after several cycles of Moore's law. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html?m=1 http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
- knodi123 11y ago
  I remember I once went to great trouble to use a succession of old computers to copy my favorite DOS game off of a 5 1/4" floppy into a 3 1/2" floppy, and then from there onto a network, and then onto my laptop, so I could take it to school with me. And in the end, I learned that the game ran so fast on my laptop that your character would move at light speed and then die as soon as you pressed a button, because my laptop was too fast. There was nothing wrong with the program, it just didn't expect to still be in use 17 years later.
  - im3w1l 11y ago
    If you still want to play it, dosbox supports adjusting emulation speed.
    - knodi123 11y ago

magicmu 11y ago

Absolutely. As a vim user, one of my favorite things about it is how it is on virtually every platform -- it's similar to what the article says about Netscape. Is the code pretty? Probably not. But I would rather have my text editor be compatible with any OS I may need to use it on than it have a readable codebase.

jayvanguard 11y ago

> It doesn't acquire bugs just by sitting around on your hard drive. Wrong. There are entire classes of bugs that have to do with adapting to new environments, security standards, etc.

bjourne 11y ago

He is talking about commercial software where the only thing that counts is money in and money out. That a free software developer should never clone and rewrite another developers software is false. Lots of successful projects are rewrites or clones of existing software, like QMail over Sendmail and vim itself over vi.

carussell 11y ago
Er, the article in question was written about Mozilla...