Hacker News Reader

Comment by chadgeidel | Hacker News Reader

I am reminded of the old Joel on Software article "Things you should never do part 1": 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.

View on HN

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."

Exactly - I (incorrectly) assumed most folks had previously read the article. Mea culpa.

May I know which article? (I mean, the article about joel's paying the price.

Background on Wasabi: http://www.joelonsoftware.com/items/2006/09/01b.html http://blog.fogcreek.com/the-origin-of-wasabi/

Killing of wasabi: http://blog.fogcreek.com/killing-off-wasabi-part-1/

Codding Horror on Wasabi: http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha...

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:)

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-...

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.

If you still want to play it, dosbox supports adjusting emulation speed.

I kinda do, actually. maybe I will.

It was this game if you're curious: http://www.dosgamesarchive.com/download/the-black-cauldron/

aka bitrot

Bitrot means degradation of physical media containing digital data, not really anyting to do with bugs appearing in code that is introduced into a new environment.

It has been used almost interchangably with code rot in this sense for a long time: http://www.catb.org/jargon/html/B/bit-rot.html

> The Jargon File, a compendium of hacker's lore, defines "bit rot" as a jocular explanation for the degradation of a software program over time even if "nothing has changed"; the idea being this is almost as if the bits that make up the program were subject to radioactive decay.

https://en.m.wikipedia.org/wiki/Software_rot

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."

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

McCoy:

"I know engineers, they love to change things"

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.

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.

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

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...

It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.

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."

Should have unit tested that comment

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.

> ... 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.

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?

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.

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.

Er, the article in question was written about Mozilla...

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.

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.

> 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.

Reply on news.ycombinator.com