Spolsky Stands Firm on Linux on the Desktop

erlando writes: "SoftwareMarketSolution is running an interview with Joel Spolsky (from JoelOnSoftware) in which he responds to this earlier thread here on Slashdot. In short: He defends his position and makes some interesting remarks on Linux and the desktop."

Comments

Justifying his earlier statement

[Mattygfunk]

SMS:...you stated that code doesn't rust, i.e., that once a piece of a program has been debugged and various workarounds added, it represents a repository of stored knowledge and should be left alone.

JOEL:It may be true for the software that Eick evaluated. It's not true for the software that I've written, because I tend to refactor and clean things up regularly.

His argument is that code doesn't rust however he argues it by saying that he "refactors and cleans things up regularly". Perhaps he needs to think about that one a little more.

Re:Justifying his earlier statement

[Greyfox]

The refactoring people tend to believe that refactoring can be a be-all and end-all. Having apparently never worked on a team in the Real World and had a piece of code delivered that was so hideous that the only thing you could really do with it is have it taken out and shot. XP Practices can help you avoid having such a hideous piece of code delivered in the first place, but you'll have a had time convincing small shops to do pair programming.

Of course, he gets around that one too, stating that if it costs more to add features to the current code than it does to rewrite it, then rewrite it. I've seen designs so bad that it's literally more cost effective to scrap them and start from scratch.

He also says that it would make more sense to have a new (and competent) programming team refactor Outlook rather than have the existing one rewrite it from scratch because the existing Outlook team sucks. That actually makes a bit of sense if you think about it. He doesn't go into how much the new team might have to "refactor" Outlook. Anyone want to make a guess?

Re:Justifying his earlier statement

[SuiteSisterMary]

Refactoring means that when you find a more efficient carburator, you install it in your car and go. Ground up rewriting means that when you find a more efficient carburator, you throw your old car in the trash, go buy a new one, and install your new carburator in it.

Re:Justifying his earlier statement

[hey!]

Although there is the matter of the initial way you look at the problem.

There's two stances you can take: (1) This is is a bloody mess, let's rewrite. (2) This thing is a bloody mess, let's see if we can't fix it.

If you look for ways to fix things, then you will find them more often than if you don't look for a way to fix them. The problem is what happens when consistently find your fixes don't fix, or break new things? I don't think there should be a general rule that thou shalt never rewrite, but that you should look sincerely and hard at fixing before you rewrite.

Re:Justifying his earlier statement

[ichimunki]

No and maybe, maybe not.

Rewriting means starting from scratch. Refactoring means doing things like analyzing existing code using code profilers and such to find weak spots or by accepting bug reports, then going into the routines that cause those bugs or weaknesses and looking for ways to improve the existing code. Maybe adding new features carefully.

Your hypothetical situation is simply too general and detached to draw conclusions from an analysis thereof. But offhand I'd say yes, much better. That's five years of finding bugs and squashing them, five years of tuning slow routines and bottlenecks, five years of security testing, and five years of usability tweaks. If you can provide all of that in just one year of development from scratch, you are a better programmer than most.

WINE-Win95

[uebernewby]

I doubt that it will be enough for WINE developers to catch up with Win95. No one uses the out-of-the-box version of Win95 anymore, do they? There's all sorts of updates you need to get your software running and, yes, those updates include additions/changes to the API.

Re:WINE-Win95

[j7953]

Big mistake. Being in the state of denial doesn't change things unfortunately. FWIW, Excel is the spreadsheet standard and PowerPoint is the presentation standard.

...and Windows is the desktop OS standard. By your reasoning, you would need Windows anyway.

But it is very possible to not use the standard tools and still communicate with the rest of the world. The real issue with MS Office is not running the actual applications on Linux, it is (as you've correctly pointed out) to access the data. Of course, Linux applications must be able to at least read MS Office files. For sending documents to someone else, you can use standard formats like PDF. Obviously, this would require some user training, but I believe that it is possible for a company to run Linux on the desktop if they want.

The non-availability of MS Office on Linux certainly is a problem, but I believe custom-built applications are a larger problem, and anyway the problem cannot be solved by playing catch-up with the Windows API.

The Tao of Programming

[juliao]

From The Tao of Programming:

A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.

These are great mysteries.

Re:The Tao of Programming

[AVee]

Thus spake the master programmer:
"Though a program be but three lines long, someday it will have to be maintained."

I guess most of you will know what happens to your room when you always move things around and add things, but never clean up...

Now there's the reason code rots. Old code tens to be changed and have things added, but hardly ever gets a clean-up. That way the design is lost, the code gets bigger and bigger and easily becomes buggy. This makes changing code harder over time. Most if the time this goes on until there is no one left that understands how it works and it has become to hard to find out, compared to a complete rewrite.

Joel states: "Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function, so over time it gets better and better."
And he makes a good point there, maintaining code should be more than just changing and adding things, it should involve clean-ups to prevent rotting of your codebase. But cleaning up is way easier if your the only one using the code, and in a company there is always the pressure of deadlines and marketing.

And of course it's just more fun to write somthing new...

Its teamwork

[cholokoy]

Most software projects are made by teams and as in any team activity, its the weakest and strongest links that will determine the success of the team.

Take any game like hockey or basketball, many teams have exceptional players but they don't win championships. Those that do play with teamwork on their minds that's why whey get to win.

Blaming marketing or second-rate programmers is not the way to go it should be a team effort wo win because not many games are played solo like tennis or golf. Even those games require seconds that provide valuable support to the player.

Bloatware does cost

[reachinmark]

Joel: Well, most people with encyclopedias only look up 0.01% of the topics in the encyclopedia. But would you rather have the Encyclopedia Britannica or would you rather have a lightweight brochure containing the top 100 topics? (You might answer: on a camping trip, I'd rather have the lightweight brochure. Fine. Get the brochure for your camping trip. But at home, where all that 'bloatware' isn't actually costing you anything, you want the full edition.)

"Bloatware isn't actually costing you anything"!? How about more time to load your application and a significantly higher probability of it crashing as the code becomes more bloated and less maintainable?

There is a gigantic chasm of a difference between "bloatware" of information, and bloatware of software features.

Re:Bloatware does cost

[Ayende Rahien]

Not really.
On Windows & Linux (I believe, not certain) pages are being faulted to memory, so if you've a part of the executable that you don't touch, then it's simply not being brought to memory.
If you've a 100MB exe, but you only use 1MB of code from it, then it will use only 1MB.

As for the other reason, any big enough project is being cut to pieces, on Windows, it's usually COM objects, meaning that it's fairly easy to dissect the parts that gives you trouble.
Beside, if you don't use something, it can't crash your program.

doesn't like "ground-up rewrites," but -

[47PHA60]

Joel seems to admire himself for doing just that, as when he talks about why his own code doesn't decay (he keeps freshening it up, you see. In other words, rewriting it over time).

This is easier to do when it's just his code, versus a large set that more than one person maintaining it over a decade (like the evaluated software that was foudn to 'decay').

Also, Joel stated that the problems with Outlook were with "1%" of the code, but that is not the point. The slashdot comment was not commenting on the quality of Outlook's code, but on the flaws inherent in the design of the application (such as executing untrusted software and not following mime type information when passing data to the OS). I think that the post was talking about a redesign, which would mean a rewrite, and Joel dodged that one (or just didn't understand it). Fixing bugs in good features is different from tossing bad features.

Re:doesn't like "ground-up rewrites," but -

[GigsVT]

Also, Joel stated that the problems with Outlook were with "1%" of the code

5000 parts per million (0.5%) of lead in your water is a lot.

It only takes one bad line of code to crash everything.

Who does this guy think he is kidding with this 1% figure?

Re:doesn't like "ground-up rewrites," but -

[Anonymous Coward]

doesn't like "ground-up rewrites," but Joel seems to admire himself for doing just that, as when he talks about why his own code doesn't decay (he keeps freshening it up, you see. In other words, rewriting it over time).

Refactoring small parts of your code over time isn't the same as a ground-up rewrite. Refactoring means you get the same functionality but with a better implementation. At no point do you lose functionality. A ground-up rewrite means you lose everything and try to piece it back together if you're trying to salvage or else completely rewrite it. I prefer not losing functionality to losing functionality. Eventually it is possible that perhaps you modify your entire code base. However instead of being a rewrite, it's really a revision or refinement. It's the difference between getting two buggy first editions (complete rewrite) and getting a buggy first edition which is refined over time into a smooth running second edition.

This is easier to do when it's just his code, versus a large set that more than one person maintaining it over a decade (like the evaluated software that was foudn to 'decay').

This may well be true in this case as it probably was written without knowledge of OOD. However, code base size is hardly of mention when your it is written in a reasonable object-oriented manner.

Also, Joel stated that the problems with Outlook were with "1%" of the code, but that is not the point. The slashdot comment was not commenting on the quality of Outlook's code, but on the flaws inherent in the design of the application (such as executing untrusted software and not following mime type information when passing data to the OS). I think that the post was talking about a redesign, which would mean a rewrite, and Joel dodged that one (or just didn't understand it). Fixing bugs in good features is different from tossing bad features.

So... why would you have to redesign the entire application? For the problem of executing untrusted software that could be as simple as an "if (trusted(software)) {execute(software);}" type of phrase. For mime type information, you could simply check with a mime-type storage mechanism and follow that. Both of these have issues (mime-type disagrees with .xxx extension - then what? Mime-types aren't perfect although my guess is you'd say to just follow them blindly) but neither of them demand a redesign of the entire application and certainly not a rewrite of it.

I don't consider "refactoring" to be the answer to everything (in fact, I'm kind of leery of the XP guys) but I also don't understand why people are quick to try to do large scale rewrites. The motto I've found to work best in my programming experiences is "Do what needs to be done." Limit yourself to solving the problems at hand and you'll accomplish your goals in a focused, efficient manner. Often, creating a whole new project instead of solving the problems in the old one is the perfect way to lose your focus on your established goals. In the case of using different languages, I could be persuaded to agree or disagree with him. Certainly, though, he is looking at the right issues (money and time costs) rather than proposing something out of sheer disdain for using an old language or because of vague reasoning of future problems - "most people don't program in that language" doesn't mean anything so long as you can hire someone that does program in that language (and again, if things like time and money aren't more adversely affected than if you ported the code).

Re:doesn't like "ground-up rewrites," but -

[ClosedSource]

Perhaps he has this point of view because the fundamental design of Linux was done by Bell Labs.

Re:doesn't like "ground-up rewrites," but -

[ClosedSource]

Linus accomplished something significant that most programmers will never even attempt, but his task was greatly eased by having a known target to shoot for. All programmers owe a debt for the prior work they're building on, but the debt is greater in some cases than in others.

On Costs

[CaptainZapp]

Now let's look at Outlook. There are hundreds of developer years tied up in that code base. 99% of the code is fine. 1% of the code isn't. Throwing out the whole code base and beginning from scratch is extremely unlikely to be cost-effective, because you have to reproduce most of those hundreds of developer years from scratch, and what guarantee do you have that the new code won't have just as many bugs

True, scrapping and re-creating Outlook is certainly not cost-effective for the Microsoft.

Unfortunately the current Outlook mess is not very cost effective for their customers, just hit by the worm-du-jour.

So I guess it just depends from whose perspective you define "cost-effectiveness".

WINE will save Linux for the desktop?

[hyacinthus]

Spolsky asserts that Linux won't be a player in the desktop market until it can run Windows applications. I find this a very puzzling assertion--one I've seen elsewhere. Certainly the case of OS/2 clearly refutes this notion: OS/2 could run Windows applications, could even run them better than Windows itself, but then, why run OS/2 when you could just run Windows, and (more importantly) why _develop_ for OS/2 when by developing for Windows you could cover both bases.

I spot a flaw in my analogy, which is that OS/2 was a commercial competitor, while Linux is "free" and therefore more attractive.

hyacinthus.

Re:WINE will save Linux for the desktop?

[Ayende Rahien]

Developing for OS/2 was harder than for Windows, because MS did everything that they could to convince developers to develop for Windows, and IBM force developers to pay for the info needed to program for OS/2
This, along with several other foul-ups, resulted in OS/2 being the inferior platform.

The Point Is...

[GeekLife.com]

That almost all new apps are *tested* on the plain vanilla Windows95. So if WINE gets to that level, all of those tested apps will work fine on WINE.

He's not saying that there are a ton of people out there using unmodified Win95, just that the vast majority of Windows programmers program with that possibility in mind.

It's an analogy

[inerte]

That you didn't seem to perceive. He was saying that removing or denying even some of the smallest features is not a good thing.

I don't see how your argument can counter-attack his. Sure, you don't run the www on your computer. But still, you 'run' the www when you browse the internet. Doesn't matter where the features are located, the point is somewhere, somehow, someone might need.

Given that he worked for MS, not very likely

[Smack]

Some programmers still do write closed source software, remember?

Joel on bloatware

[Anonymous Coward]

> SMS: Another interesting point was raised in reference to bloatware... Do you
> think a product like Microsoft Word would benefit by having every feature that is
> used by 1% or less of the installed base removed from the product?
>
> Joel: ...The WWW is bloatware. Finding things is impossible because there's so
> much stuff out there. Think how much hard drive space is wasted on all kinds of web
> pages that only .00000000001% of the world ever reads. Since the vast majority of
> people only go to Yahoo, Ebay, and MSN, wouldn't the WWW be better if it only had
> Yahoo, Ebay, and MSN? It would be much more "optimized."

With Joel from Microsoft at the helm the entire contents of the Internet would reside on a single loooooong web page.

The oposite of MS-Bloatware (TM) is not lack of features. The opposite is UN*X's lean tool approach. Use tools for one function or a small set of tightly related functions. Create a screwdriver to screw screws, a hammer to nail nails. You do not create a Rube Goldberg machine with a flight simulator.

___
Anonymity is freedom!

Re:Well...

[ergo98]

You're preaching just as much as Joel ever does, so I don't really understand why you're accusing him of a superiority complex. If you are bothered that Joel has a platform, realize that it is the result of many brilliantly insightful articles that he has written (that's my opinion, anyways. Especially concering UI matters where it is eye opening and humbling).

However, I think everyone here is taking what Joel is saying GROSSLY out of proportion : There are two poles in software rewriting -> Those who approach every issue with a "we have to rewrite this piece of crap" (these programmers are common and have cost companies billions in cost overruns. "Hey Jim I noticed on that report that it's cutting off the interest rate at 5 characters : Do you think you could increase that to 6?". Then, six days later Jim replies "Oh man, I looked at that code and it's horrible! I'm going to develop a mega new reporting engine in C# that'll use an XML subsystem". Three years later the six character interest rate still isn't there. Again this is common because many programmers do not have checks and balances, and it's much more heroic and personal to rewrite the whole thing and lay a grand claim to fame than to just do a quick fix isn't it? On the other end of the pole are those who treat all code as sacrosanct : From what I've read Joel is not one of these people. Exactly as he stated (which many people jumped on as hypocrisy where there is none): He is an advocate of refactoring, which as a philosophy is entirely unlike rewriting.

Let me put it another way: Every now and then I watch one of those HGTV shows where they remodel a home, and sometime I am stunned because in the end they've replaced virtually the entire house, so naturally my question is "Well why didn't they just bulldoze the original house and start from scratch?", but obviously there were benefits to going on the existing infrastructure. This fundamental holds significantly more true in software engineering (hehe, I use that term just to bother the PEs out there) because as a discipline it is far more "artistic" and far less defined than home construction. Why, then, are so many people so willing to rebuild from scratch with no proof of improvement? I can't make comments on your specific project, but in the grand tradition of program rewrites, you'll complete it and find that now you can handle 210,000 connections, so you'll just have to rewrite it again...

Re:I never contradict myself ... well sometimes I

[e-Motion]

Sounds like he could save quite a bit of time and maintanence nightmare if he just invested the effort to write it well the first time.

Yes, software development would be a breeze if we could write perfect code the first time.

He replied to the wrong argument

[Tony]

Joel was commenting about a study that indicates that software does "decay." In one old project, a lot files had to be touched for a simple change; then, after what amounts to a "refactoring," changes were more localized. after time, the old situation recurred, in which a lot of files had to be modified for a change.

Joel's reply (paraphrased) consisted of, "Well, perhaps for *that* study. But *my* code doesn't rot. I'm constantly refactoring it!" So he claims the study doesn't apply to his software, because he's constantly refactoring his code.

He needs either to read the questions before answering them, or get struck repeatedly with a Very Large Cluestick.

Thank you, Joel

[jquiroga]

I could rant a bit about how wrong (or right) Joel is about lots of topics, but that would be a little redundant.

Instead, I would like to say thank you. Thanks, Joel, for writing about your opinions and experiences, the lessons you learned, what you did wrong. Thanks for taking the time to tell us. It doesn't matter if we agree with you or not. Thanks for trying to help, you centainly help me a lot.

Re:Thank you, Joel

[Anonymous Coward]

Is it possible to moderate a comment (-1) Sappy?

Re:They Stole A Slashdot Interview!

[Geek In Training]

...shouldn't they at least have to ask before using slashdot content for their own means?

Legally, they don't have to do any such thing. What would be nice, however, is an oft-forgotten concept known as Professional Courtesy.

It went out of style sometime between when the entire corporate work-force was made up of white male WWII verterans who wore white shirts and black ties to work (at leats on TV); and the high-ranking executives of companies like LTV Steel in Cleveland taking 17 million dollars in bonuses three weeks before the company filed for bankruptcy, putting three thousand blue-collar steel guys in line for unemployment benefits with no pension of health coverage.

Sorry to be offtopic... yes, it would have been nice for them to ask, but now that professional courtesy is dead, I'd be more surprised if someone DID ask permisson than if they just did whatever the hell they wanted for an almight buck to make sure the CEO gets to buy the "big yacht" this summer.

(And FYI, "Flamebait" does not mean "I disagree with this person." Point down your modpoints for a minute and take the time to write a thoughtful argument. Also, I work for a corporation, and I am critical of corporations. It's not hypocracy, it's called "taking a stand for change from within.")

Funny stuff here...

[GooberToo]

It's not true for the software that I've written, because I tend to refactor and clean things up regularly. Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function, so over time it gets better and better.

In other words, his code decays MUCH faster than anyone elses. Glad he doesn't work for me. At "half the time", that means he's costing any project 50% more in his time/dollar worth. Ouch!

Don't even talk to me about spending money replacing something that works.

No, he doesn't replace an application at one time, it does it over a period of time, one function at a time. LOL!

Well, most people with encyclopedias only look up 0.01% of the topics in the encyclopedia. But would you rather have the Encyclopedia Britannica or would you rather have a lightweight brochure containing the top 100 topics?

What? I thought they were asking about optimization and maintaining code that no one used?!?! Perhaps he answered a different question for Reader's Digest and was confused.

The good news is that a lot of stuff I write about UI is starting to have an impact on the Gnome and KDE people. There's a lot more appreciation for the value of good UI than there used to be in the Linux community. Once every open-sourcer has seen their marriage break up by installing Linux on their non-technical spouse's computer, they'll finally understand that, no, most people don't prefer command lines.


Hmmm....and I thought this was a process of evolution simply because neither KDE or GNOME can snap their fingers and have everything under the sky that makes everyone happy. Gosh, it's taken MS how many years and they still don't have it right. Suddenly this is all about you Joe? Ya, I'm sure the face of UI is changed because you're the only one that can understand how computers are used. Oh ya...I forgot...you're the only one with parents that use computers...

Well, I write code every day, and have done so for most of the last 20 years. I think this is pretty self evident if you read what I write on my site, but slashdotters are not exactly famous for reading the things they are commenting on!

Seems I read what you said and I must say, aside from your high opinion of your self, you don't seem to understand much else.

Woa, alotta woa..

[dmouritsendk]

I havent read the first article they refer to, but the linked-interview give you a pretty good idea about what it was about.

An I must say, it baffels me anybody want to argue with that guy. He one big contradiction,but i wont even comment on this since i saw a few comments on that subject
already and this really talk for it self:

that once a piece of a program has been debugged and various workarounds added, it represents a repository of stored knowledge and should be left alone

a bit furter down the text we see(as a counter to a argument from a slashdotter):
It's not true for the software that I've written, because I tend to refactor and clean things up regularly.

But why not argue his point with him?Conversation/discussion is a be good, and people tend to learn from it.

Because hes a pain-in-the-***. You ever met one of thiese programmers who made a obvious mistake. But you need to argue 28 minutes with them, begging them to fix it. And they throw alsorts of wierd examples at you, just prolonging getting the job done. Thiese guys dont want constructive input, they just want to be right.

Joel needs to chill out. And stop talking about people that doenst share his views as interlectual inferiors("But not everybody writes code well" , "younger slashdotters" etc).
Learn to have a discussion without creating lame examples to "protect" your own argument. Im thinking about the Encyclopedia example.. Thats the worst B******* ive ever read.

If you buy a encyclopedia, its probertly to access to information about stuff you want to learn more about. Hence the "applications" job is to provide information, having only 100 words would be an incomplete application. The entire purpose of an encyclopedia is to provide you with information you didnt know you needed when you bougth the books.
A wordprocessor application which doensnt feature the newest 20meg office assistent, text taperingtool, access integration etc. couldnt be defined as an incomplete application, just a application with is less rich on features. Bacially the applications can do the same thing, create documents. A 100 word encyclopedia wont do the same job as a full one, so, they cant be compared.

And for the WWW example, again same thing. Information gaterhing. And even the younger of us slashdotters know that what is great about the WWW is that if you are one one the .00000000000000000000001% people that have a craving to read about fishing in nothern norway(or some other wierd thing), the WWW will have a page for u(and btw. what the freak would be the purpose of having yahoo if they only could index ebay and msn? doooh!).

Simply put, so even the older-softwaremarketsolutions.com-article-authors- with-overinflated-egos can understand it:

A WWW without webpages, or a encyclopedia with 100 words is not comparable to a wordprocessor/emailclient/what-ever-app with out office assistents , 3D logo generater, HTML wizards, Office exporter.
Its more comparable to a wordprocessor with out keyboard support.

Excellent point

[GCP]

Office now requires RichEdit 3.0, version 3 of the *system control* RichEdit. Since Win95 only has RichEdit 1.0 by default, an Office installation has to upgrade the OS -- and it does.

Interestingly, Microsoft does NOT allow ISVs to distribute RichEdit 3, nor do they make it available as a simple download from MS.

This creates two classes of application vendor. First class vendors are those named "Microsoft", and they are allowed to target the entire installed base for maximum revenue, upgrading any OS version to *make* it meet minimum requirements.

Second class vendors are all others, and if they need the same thing Office needs, RichEdit 3 for example, they are advised to get their customers to go buy an OS upgrade from MS.

Whether this is "fair" or not isn't my point. MS owns the whole platform. You can have any scraps that they don't want.

If you clone the Win98 API, apps from second-class vendors, everyone other than MS, will probably run fine. The apps from the first-class vendor, Microsoft, probably won't.

I say "Win98" instead of "Win95" because of the large number of vendors who have ceased to support Win95. If they can't upgrade the OS themselves, they either have to give up older OSes or give up some functionality that people are used to having in MS's own apps. Most have chosen to compromise, giving up some market, the Win95 platform for now, as well as the most recent nifty(Win2K+) features. In a couple of years, these vendors will be giving up Win98, too, so WINE *does* have to keep moving.

That's the nature of the platform. There are two "installed bases", a big one for MS and a smaller one for everyone else.

MS has made "3rd party horizontal app" an oxymoron on their platform. If WINE wants to run the most popular (a.k.a. "horizontal") apps, it has to keep up with the latest OS versions. Lotsa luck.

You are all missing the point!

[humblecoder]

I've read a lot of the comments on here, and I think that many of you are missing the point of his argument that rewriting is bad. If you re-read the article and if you read his original rant about rewriting code on his web site, you will see that he doesn't say that you should never rewrite code. He is saying that if you choose to rewrite code, you better have a sound business case for rewriting the code.

I think his position stems from the fact that we coders out there love to rewrite things on a whim. Often times we as coders like to work with pristine code, and we find ugly code offensive (even if the ugly code works). However, his take is that unless you can show that the cost of rewriting outweighs the benefit, you should leave the code alone.

In most cases when you have a piece of working code that does the job, the cost of rewriting it from scratch is very VERY high (higher than we coders think). Therefore, you should think long and hard before going down that path.

At the first company I worked at out of school (a large financial institution), I had the misfortune of working on a large, monolithic FORTRAN app. This app was one of the worst messes I have ever seen. It was originally written by a financial guru who knew just enough about programming to be dangerous. In time, many programmers had come and gone and added their own bug fixes and feature to the code. By the time I had gotten to it, it was a bear to make changes to. My first thought was that this app should be rewriting from the ground up. In fact, I started working on a project to replace the app. After a few weeks I came to the realization that rewriting the app was a waste of time.

The fact is that old FORTRAN app worked! To create an new app that would completely mimic the old thing would take many, many man-years. Sure modifications to the old app were a pain. However, it took less time to make the modifications to the old app than it would take for me to rewrite the whole thing.

In the end I put aside my snobbish attitude and learned a little FORTRAN!