A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
From a related topic, I've been led to http://www.joelonsoftware.com/articles/fog0000000069.html
If I'm not mistaken, the article is written 13 years ago and people are still supporting the opinion. Maybe I didn't get it? Old code works, been tested, don't throw it away? Nowadays, a well up-to-date software to the new standards has nothing equal to the code it was in the late 90's. Isn't it? So the code is literally gone. Thrown away, or saved in backup files no longer used in production.
Let's give an example with PHP.
In the past more than decade PHP turned from a small procedural language which makes things dynamic instead of static HTML, with a short support of basic database (mysql_) libs, to almost object oriented language with good amount of libraries, frameworks and model patterns.
So, tell me now, how to reuse the code, where, whenever i.e. a user in a virtual platform, with virtual money, uses something it runs a query to the database which updates its money (take away), then prints something on screen. Laying on that archaic model, we are not designing a controller and a model, with the new libs for databases (which have not a single line of code equal to the old ones), which takes care about the 'user money', and a view where prints on the screen whatever the model returns to the controller's call.
We don't even use the same loop operators as we did, not even the same checks.
Only the "want-to" is the same. We now want to, once again, to display the user, we took him 10 dollars from its virtual money. But we are not using a single line of code, as we used. We don't need that code. And if we want to add new features which manipulates its money, it will be walk to hell and back if we are strict to the old standards. And when they they'll be gone, when we update our PHP version. So, we are on the bind, where we have to rewrite ALL the code from a "bunch of code" to a designed architecture.
Wouldn't be easier and better, if we have the "want-to", to rewrite it from the beginning, instead of reading a 15 years old code, and telling ourselves "a-ha, it was doing this thing, so I will take this variable, use the function from here and will write a method which takes care about it. Oh, and lets use that loop, which iterates through the results".
Why not to spend myself (or the dev crew) time - days or a week, to migrate the code from archaic standard, to the most new standards, with lots of support, rather than spending months on adding new features in total mess?
You misunderstood the article. It didn't say 'don't stay up to date', it said 'don't throw everything away and start from 0'. Luckily there is a case study of the exact example you use that proves that in the real world, the article still holds: http://symfony.com/blog/dailymotion-powered-by-symfony . Huge site moved from old bunch-of-php-files to Symfony. Didn't do it by putting everything on hold and locking dev's into the basement for 6 months until they had finished a functionally complete duplicate of the old site, but migrated slowly and controlled to new tech without disrupting business requirements.
"good amount of libraries, frameworks and model patterns."
It doesn't seem that long ago when we had to quit trying to maintain some websites in-house because moving to PHP 5 required a skill set that none of our staff had. So there is something good to be said for dropping old code.
The acceptable quality standard for computer services delivered online is much lower. If a web service is broken, it's not a big deal, we go back to doing business the way we used to. If it costs too much to fix, we contract for a new service to do something similar. Really all that is needed is to connect to our mainframe data sources and to make the dynamic web pages look familiar enough that users don't have to learn too much. Oracle and IBM provide the first part, and we can always find a contractor to customize a framework for us. It's still dressed up CRUD programming.
If it works, why change it? If it does not, why change more than you have to?
There is no absolute answer to these questions, but they are worth considering before you decide which way to jump.
Maybe, you really do need to rewrite that app. You would not do so if the app is not useful. Since it is, you had best not mess up using it in the meantime. And if you do not have to rewrite it, do something else.
It might be more useful to write an app in a different area that does not have something for it.
I have an old app of mine (15 years old). It still works. Some of it, I cringe when I look at the code. BUT a business is run using it.
From My Sig Collection:
legacy (adj) - A pejorative term used in the computer industry meaning "it works."
1-2 developers and a handful of customers, and you are the boss, full rewrite, sure. Anything more than that is more often than not going to be doomed to failure, most likely at the point where someone has to get funding for a project with no solidly quantifiable benefits.
As someone (maybe me) once said, there are 2 kinds of software, software that is coded and architected nicely and refactored/rewritten periodically ... and software that people actually use.
"Don't fix what isn't broken." It's as simple as that. Some people just don't get that, though. Don't know why.
An old app from the 70s that does it job perfectly well with no future changes needed, and was written in spaghetti-code Basic, will benefit absolutely NOTHING by being re-written today in the latest gee-whiz language. People need to grasp that concept.
As Joel said, code doesn't rust with age.
If I remember right, "Don't rewrite" articles came out around the time that the open sourced Netscape code was being rewritten into Firefox. The context was for enormous projects where rewriting takes a long time. An argument against is you lose functionality of strange edge cases and such that were captured in obscure bits of code in different places.
It took a while but Firefox was right, rewriting was the right solution.
However it is important to understand that Firefox was not a replacement for Netscape, it is a competitor for IE, Chrome and Safari, and it's free, so it's not the same situation.
I'd say be cautious still on huge projects of a product you sell.
With small projects that can be rewritten in 1-10 days, why not rewrite. I've done it and it was the right thing to do.
Very old BASIC programs were mentioned. Computers back then had 4k-64k of memory. Most of those programs are better rewritten.
Some tips. The best success is if you can semi-mechanically translate.
When I last converted a BASIC program to a C, I set up a bunch of functions and defines so that I could mimic the primitive BASIC architecture. That got it working with no errors quickly.
I later translated the C to Python and it was straightforward.
Here's another example. I had this fairly sophisticated Python system running on one server that was bogged down. It was recommended to add additional servers and rearchitect the system to run on multiple servers. Instead I translated the Python to Perl (took a day or two) and now it has room to grow since Perl is much faster than Python and the growth curve is not exponential. (For exponential growth going to multiple servers would have been the way to go.)
Really good example with Symfony :)
However, it seems to be different to develop a downloadable app and an online one.
Let's talk about online browser games, where I'm involved in. It's still a software. Without mentioning names, a decade ago or so, a company released its first online browser game. Low standards, and maybe not so pro developers by this time, so the code was worse than spaghetti one.
Through the years it was really hard to introduce new features once or twice a week. You know, the users (players), need new stuff on daily basis, because they are getting bored by the time.
But all these new features needed changes in old code, making the performance slower and slower. So they came to a point after some years. The dilema where they need to rewrite almost the whole game, or start from the beginning.
So they dropped the support for this game and started to develop a new one, and in less than an year, they released a new game, with new name.
5 years have been passed since the new game was released, and they keep introducing new features without problem once or twice a week.
What do you think? Was it better that way, to leave the old software unsupported, and start developing almost the same, but new one, with better code manner, or keep working on spaghetti code, and everytime you need to change something, to rewrite and for each feature to lose 3 weeks instead of 5 days?
I've had a reasonably long and varied IT career programming and project managing IT developments and from personal experience the worst two IT disasters I've been involved in were "rewrites".
The attitude being
"We're better than the last bunch of programmers" and "This time we'll do it right."
Well that's a very arrogant position to take and what we found is that:
a) The problem was harder than the simplistic "Perfect" model we had in our heads.
b) There are always lots of annoying real-life details that make your simpler model ugly and unworkable.
c) That the customer doesn't give a fig that you have written "better code".
d) That your customer suddenly finds bugs in stuff that used to work ....
e) That your management team don't give a fig that you've written "better code". They just want to understand why you've spent $1M to produce the same product that you already had.
f) Your competitors are in the same place .... except they spent the $1M improving the "old" version so now they have more features.
g) Team disharmony was introduced .... some people got fed up with working on the "Old" version when all the investment was going to the "New" version even though it was the old code that was making money and the new was just sitting on the shelf.
I am not saying I would never re-write. Life and projects are to varied to ever rule something out entirely but I would have to be convinced that we were completely at a dead-end before I did.
Harry Phace: "As Joel said, code doesn't rust with age."
I wish. I have some utilities that I have written for my own use in programming. They are written in a 16-bit version of QuickBASIC. They run fine on my XP system, but they do not run natively under 64-bit Windows 7. On some versions of windows 7, you can run them using XP Mode, but XP Mode does not run on some versions of Windows 7 (such as the one on my laptop).
"So they dropped the support for this game and started to develop a new one"
This is a good point, some software expires on its own, and forget about rewriting the same program, just let it starve and start with something new. So you don't bother rewriting, you replace.
You can't do that with accounting software, because there has to be continuity for auditing, and you can't do that with software to schedule manufacturing production because the company depends on reliable output. In both cases, the entire organization is trained and experienced with business systems that the software has to work with, not business systems that have to work with the software. Sales and marketing, on the other hand, keep getting re-invented at the business process level, so there is no reason not to replace software whenever management feels the urge.
"They are written in a 16-bit version of QuickBASIC."
Now why doesn't someone rewrite gorilla.bas in Win32?
Gene Wirchenko: "They are written in a 16-bit version of QuickBASIC."
Howard Ness: "http://support.microsoft.com/kb/282423"
It is titled "List of limitations in 64-Bit Windows". I already know it does not work, and this article does nothing to help.
HN: "Now why doesn't someone rewrite gorilla.bas in Win32?"
What was that?
My point was that some software is disposable and some isn't. If it's disposable, don't rewrite, replace instead. It also occurred to me that the disposable portion is growing very rapidly relative to non-disposable software.
Gene Wirchenko: "They are written in a 16-bit version of QuickBASIC. They run fine on my XP system, but they do not run natively under 64-bit Windows 7"
Harry Phace: "That's not the apps' fault. That's just planned obsolescence from Microsoft. Their code is as good now as they were back then."
No, it is not. Code is only good if it runs.
rewrite qbasic... I'm not joking!
I started to develop a program using dBase III+ in 1987 (yes, 1987). Later that year I converted to Clipper, a compiler (pcode based) of the language.
There were some tries to gui based porting of the language (ms foxpro, borland visual dbase, CA visual objects)
Then there were some commercial porting and finally an open source project (2, there was a fork), Harbour (now on github).
My 26 year old code is now ported to 64 bit and I can have it run on windows, linux, osx, several embedded systems and on blackberry 10 (using qt libs) and betas already running on iOs, windows 8 rt and android GUI...
Legacy code can be extended to support mysql, generate pdf, using windows printers... oop was added too.
so, is it necessary to rewrite from scratch using new programming languages and tecnologies? Well, not always... but I may have been lucky :-)
A friend of mine takes care of a 30 year old payroll mainframe program, a mix of cobol and assembler with cics calls...
Harry Phace: "The code does run. Just because the platform has changed, doesn't mean the code is no good. That's like saying a book is useless in the dark because the light's turned off."
Not on what would be my dev box.
The code is not good on the new system.
You can turn on the light. What is the equivalent in Windows 7? (XP Mode does not run on all versions.)
Gene gets it fine. You're saying that theoretically, using an interpreter that no longer exists, the software works.
Gene says that's not a practical response since code that doesn't run in practice isn't usable and therefore is broken by definition.
It's similar to when there is an OS update that has bugs or "deprecation" decisions that result in an API not working the same or at all, killing legacy software.
The software is broken from the perspective of the person running it.
The pedant says no, software doesn't rot, the software worked and hasn't changed therefore it still works.
The pragmatist says, the software doesn't run.
The pedant says, all you need is a theoretical machine that doesn't exist anymore.
The philosopher then says, let us make our programs be random noise and then declare them to work perfectly since theoretically a machine could be built that interprets that random noise and does exactly the task we are hoping it will perform.
This greatly simplifies the process of programming. Any "working" program can be made by generating a random number sequence. There is only the small matter of hardware to run it on.
Thanks Scott, now I can relate software development to the second law of thermodynamics, "the entropy of an isolated system never decreases." Which is another way of saying that the degree of chaos in computer programming will never be lower than it is today. Sobering thought, that is.
Yes, it's not strictly the same but there are parallels.
I see bit rot as a real thing. Outside of embedded programming running on unchanging hardware, all software has tendrils linking it to other support software, OS calls minimally, but language and system libraries, frameworks, etc.
Each of these may be at any of a number of versions which may or may not be compatible with the others or your software on a given machine.
Software is built on a foundation that is just as likely to be crumbling into decay or dissolving into sand as it is to be something that is being strengthened or shored up. If it is being "worked on" it is far more likely that baroque complexity is being added that will destabilize things as the original architects are long gone and those who have come after don't understand the system they are changing.
Scott: "Gene gets it fine. You're saying that theoretically, using an interpreter that no longer exists, the software works.
Gene says that's not a practical response since code that doesn't run in practice isn't usable and therefore is broken by definition."
You nailed it.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz