Slashdot Mirror
What Happens To Code From Failed Projects?
Idzuna writes "With the somewhat recent announcement of Tabula Rasa shutting down, I have been thinking about what will happen to the Server/Client code. Does it get used as a guide for other projects? Does it get destroyed? Or does it just sit there on a hard drive somewhere in storage? The same question applies to many other failed creations. I know the likelihood of the code being distributed freely is next to nil, as most companies probably recycle code. If a vulnerability was found in old code, it could be applied to other products that the company has released. But wouldn't it help development of different projects if such a resource was available?"
They go to the little /dev/null in the sky.
The code is used for other projects by the same company. Few companies release their old/failed code -- id being the only game company I know of that does so (GPLing their old code).
Disconnect and self-destruct, one bullet at a time.
. . . it just fades away.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
all have copies at home.
We recycle code. We have to separate it ourselves though. There are code bins for C, Java, Javascript, Perl, and Python. It's pain though! Every semester some intern puts Javascript code in the Java bin and the other way around!
But it beats having the code end up in a landfill!
That really depends, if it fails really badly then it gets buried.
Summation 2
Some have described a tunnel of bright light where the code executes in an infinite loop forever.
Others theorize an ultimate review where code structure is judged. Good code may branch anywhere at anytime with an infinite clock speed and infinite memory space regardless of pointer size. It is said that in the code afterlife, even vista will run quickly. Bad code, say like MS BOB, will spend eternity in some embedded device like a clapper or firmware that controls a japanese toilet.
Where I work if a project gets shelved we separate any useful functions from the code and copy those for future use. and then the code gets archived and a document of its code printed out on paper for reference and as a hard backup. Basically its recycled, although we've had clients come up after 5 years wanting to restart the project, and are surprised that we still have it.
It just sits and waits for an approval, so it can be given a decent burial within the Yucca Mountains.
I've never worked on a project like this, but on other things I've done, I've used it as a learning experience. We always learn how to do things better over time, even if they're not the same type of project.
Depending on the project, I've either kept a copy of my code somewhere safe, or I've just remembered "oh, it took this to do it well", and then do it again but better next time.
I've known people who recycle their code directly. Unfortunately, that makes their errors follow them, and they reuse bloated libraries over (and over and over). On some, I've had to clean up, where I've found multiple things that do the same or almost the same things, and many things that were simply unused and had no application in the new project. Why should you have 10,000 lines of code, where only a couple hundred do the job. Sometimes the leftovers contained subtle but exploitable bugs. Is it worth saving a little time to leave a potentially dangerous bug in place?
Serious? Seriousness is well above my pay grade.
What happens to a code deferred?
Is it ignored
with no more patches to come?
Or sit there, abandoned --
and never run?
Does it become obsolete
Or turn into freeware --
to become something sweet?
Maybe it's reused
To spawn newer code.
OR DOES IT EXPLODE?
Goo goo g'joob.
To paraphrase the old saw about decisions:
Writing good software requires experience, and experience comes from writing bad software.
Have you read my blog lately?
Doh! It gets patched every second Tuesday of the month.
Say hello to my little sig.
In my observation at a commercial software firm:
1. Product is canceled / killed
2. Developers that know anything about the project are axed or leave
3. The source control repository sits untouched for year(s).
4. SCM admins decide the project really is dead, and it can stop wasting prime reliable/backed-up-/offsite storage. Project is archived to offline media.
5. Now the project is not online, people that worked on it are gone, and managers that worked with it don't want to remember. After another few years people barely even remember it existed.
6. What's happened to the code? It literally is sitting on physical media gathering cobwebs.
-Malloc
___________________ I want to be free()!
When EA shut down Earth & Beyond, there were the typical calls for the server software to be released. Amazingly enough, they actually did get a response: that the code for the backend of an MMO represents a huge investment by a company, and that they (EA) would not release the code for two basic reasons. One, access to the code (source, libraries, decompilable libraries, whatever) for a fully functional MMO would be a huge leg-up for competitors attempting to enter the field. Two, the code represents a base that can be used for other projects, and releasing a version of that base could be a liability to those future projects. For those two reasons, the chances of EA in any way supporting community-run servers would be nil.
Not stellar news (nor surprising), but the one pseudo-official response I have ever actually seen. And it does make sense, to me at least.
Right, but even Larry Ellison can't buy every software company out there.
Code is easier and more fun to write than it is to read. The first hurdle in front of this magical "re-usable resource" is that no one even wants to take the time to read it and decide if it's any good; the natural inclination is to write your own.
Secondly, programmers are just as crowd-driven as anyone else; re-using code from a failed project is swimming upstream, just like writing code in an unpopular language.
Third strike -- potential legal encumbrance. On the off chance that your project is successful, who know who might come out of the woodwork with a potential claim against it? Look at the SCO Linux lawsuit; even if the claims against your project are totally bogus, they'll still suck years out of your life.
"Nothing was broken, and it's been fixed." -- Jon Carroll
This jives with what I've seen. Although I'll add the additional, final step:
7. Someone decides to clean out that closet full of accumulated crap, asks everyone if they know what the "FooBar_02" project was all about, and hearing nothing, throws it away.
If it's stored on hard drives, tapes, or other reusable media, somebody might at this point grab them out of the trash for re-use at home, but if not they just go to the landfill with the rest of the garbage.
Maybe at some point in the future, archaeologists will puzzle over the more well-preserved specimens, wondering how we managed to survive with such crummy software.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Nothing for 6-digit uids?
I always thought it was really cool of Volition to release the source code to Freespace 2 after Interplay's demise. It's allowed a whole ton of custom mods and campaigns that I'm still playing today, 12 years after the game's release. Textures and effects were updated by the mod community and a lot of the new campaigns include new ships or weapons. Some of the best include:
Beyond The Red Line (BSG conversion with Newtonian physics)
Blue Planet
The Procyon Insurgency
The Babylon Project (Babylon 5 conversion)
Murphey's fighting Occam, and we're in the stands.
People who don't write code seem to think that it's like a made thing, which, once made, has some level of intrinsic value. This is not true. Poor code can have actual negative value (it can even be destructive to a company). Even good code which solves the wrong problems can be a huge hindrance. Failed projects and companies seldom fail simply because they were technically excellent. [I'm not saying it doesn't happen, but I am saying that it doesn't happen all that often, and it's often impossible to divorce code from its context.]
I still get requests to open-source a package I wrote 18 years ago for an OS which hasn't existed for 10 years. I wrote the original version of the package while I was a fulltime college student, in the two months before finals. I certainly went on to put another 3 or 6 months of fulltime work (spread over years) into improving it, so there's certainly some value I put into it. I don't think requesters really understand me when I suggest that if they were REALLY capable of using my code as a starting point, they would easily be capable of simply starting from scratch. There's maybe 10% of the code which really has value, but anyone talented enough to be able to pick that 10% out and repurpose it would probably have no desire to do so. I know that if I were tasked with solving the same problem, I'd just start over.
Borland has released code for several products. They stopped making C++ Builder a few years ago. I wish they would release that code to open source. Eclipse needs a visual editor for C++. They have one for Java, but not for C++. It could work with the QT libraries.
I took the opposite approach at my current job. After computing the cost to maintain a line of code (around $10/year,) the logical solution was to delete all unused code. The payoff was great: no more worrying about breaking compatibility, smaller, cleaner codebase, etc.
Another plus was that shelved code tends to be bad code: if it didn't suck, it would still be in use. Maybe it had some useful gems in it? Possible, but doubtful: usefully gems should have been in a common library, not a cesspool application.
A final benefit was that it made paying the programmers much easier. The author of 10K lines of code that were being used got paid a lot more than the author of 20K lines of code that were deleted.
Remember the last scene from Raiders of the Lost Ark?
I used to work in four different companies. From my experience, the code will be forgotten for good.
As a first, software products are typically poorly documented. Typically, some documentation is written *after* the project. If project has failed, the chances are that even post-mortem documentation would never be written. Without documentation, there are small chances that someone will be able to use the code.
Technologically speaking, code reusability is generally very low. Except if it is some framework (which by default means that it is for reuse), sometimes even small changes in business logic may lead to significant changes in code (if it affects some assumptions that are made early in project). Different project would probably require too much change.
Even if the same programmer needs to be swapped to the new project, very few code will be taken to it. But he will transfer his experience, which is not a small asset.
I will give you one small example. I had to write a TCP stack simulator. I was contracted to write a TCP over ATM simulation. My plan was to give a code as GPL after the release (no legal problems there). Project started very well, with nice OOP architecture and everything. As project went further, I noticed some errors in design, but it was too late to change them. The closer we were to the deadline, there was more and more bad code inserted. Not that there were many bugs, but it was not that elegant as it was in the beginning. Finally, no matter that simulation worked quite ok, I was not that impressed by idea to give it to the public. Simply, code was in a need of a refactoring; documentation was almost non-existant; I had no time or motif to work on any more.
That project was a success, but would there be any real benefit of giving that code to someone else to use it? Now imagine if that was a failed project - same thing but with bugs and without any results. Who would ever like to use that?
No sig today.
It becomes firefox.
Amiga and BeOS, etc One that annoys me is I have some old mac classic machines, still useful if I could get say like classic 8.6 from apple for real cheap, but it is unobtanium. OSX certainly won't run on them, 9.xx is bloated, I'd pay apple a few bucks to download 8.6 or have it shipped on a disk, they don't want it. Look at Redhat when they stopped selling a cheap boxed version. They used to get 60 bucks from me, now it just costs them for me to get Fedora for free, because I am not going to pay hundreds for some "workstation" desktop release, but 60 or under (like ten or twenty bucks for the disks and access to the repos) I might think about if it was stable and supported for several years with just official updates. I'm on dialup so I just buy them from the disk clone makers, redhat gets not a penny because they just don't want the money or something.
I don't like fedora's twice a year release,it is too rushed, but I do it anyway because once the newest stuff is out the older version gets seriously neglected even though they offer some patches and whatnot, you can tell it degrades fast. But I would rather just get stable code and have a little money going to the developers. They don't want it unless you give them hundreds. Ta heck with that. So there is CentOS, but the devs and company at redhat still get no money. If I was a redhat shareholder I'd be complaining about that bigtime. Copies are cheap, why don't they try to make a few bucks?
Sometimes things just don't make sense with corporations. Detroit destroying their initial electric car efforts (that were pretty good actually, the EV1 and electric Ranger where decent vehicles) on purpose so the Japanese could come in and grab that market, now they need a bailout. Crazy corporations. I think sometimes the guys at the top levels get so far removed from day to day reality they just get a case of the stupids from megalomania or something. Back to the cars, when the CEOs all flew in on the jets, they got laughed at, when ANYONE with a clue, basic PR 101, would have told them to drive in with their best efforts and concept cars, like they just did last week the second time they came in to DC to beg for bailout money. The Cxx whatevers just get detached from normal middle class reality because they are just too rich and used to giving orders and think they are infallible, can't even see a lot of things anymore so they make boneheaded decisions with their markets.
Look at the MAFIAA tards who just don't get it that 20 bucks for ten cent plastic disk with some ones and zeroes on it is serious price gouging, because $20 to them is a dropped penny on the ground, all the big bosses in the music and movie industry are multimillionaires surrounded by yesmen toadies. So they wonder why piracy took off. They just don't get it.
So... 10K used lines gets paid more than 20K unused lines...
return 0;
Here we have one line that is used frequently! That'll be $4 million. I accept paypal.
I guess I didn't express myself well. I don't care about KLOCs, I want problems solved.
I get very annoyed at programmers who claim they are productive because they wrote 20K lines of rubbish. So, I fire them and give the freed-up money to the guy who wrote 10K lines of useful code.
And, yes, I do understand that some things are one-shot projects (e.g. data migrations.) Using my super-manager powers, I explain we will get paid for getting the job done, not for writing pretty stuff.
I was lucky enough to have a 10+ MLOC codebase, plus version control history on 500+ developers going back 10 years. After writing a shredder/hasher to look for cut and paste programming, was pretty easy to divide commits into new development vs "maintenance." This gave rough $/line numbers.
Then asked a number of developers to estimate their time spent checking/maintaining compatibility with existing code. Numbers mostly agreed with the version control numbers.
Finally, went to some managers and asked how much they would pay to have 1K, 10K, 100K LOCs removed. Again, numbers matched reasonably well.
I don't claim science here: estimates varied from $1 to $100 per line, but $10 was a number most people were comfortable with.
http://www.oldsoftware.com/old_parts.html
I don't know how one can run a business selling junk like this, but all those old CD's wind up at the bottom of the food chain.
Of course, you may need to broaden the term 'failure' to include 'shipped, but failed to sell'.
If you post it, they will read.
Honestly, if you're lucky, several of the lead developers have kept copies of the source of their own (legally or otherwise), and have a decent idea about what is and isn't worth reusing. I've seen this in a few places, both very big and small.
The brightest people I've seen (coders, managers, producers, etc) have "personal scrapbooks" of this sort.
If they're still at the same company, or otherwise have rights to the code, they use or encourage use of the code directly; if they're not, they generally use the practices and ideas to implement it again. New implementations on the same ideas can be even better than old ones.
If you work someplace with some examples of great code or ideas, it's worth prodding the authors until you understand the hows and whys. Often, if you get the reason behind _why_ something was done the way it was done, (re)building it becomes much easier. People generally enjoy explaining if you take an interest at an opportune time. This kind of information can be even more valuable -- and yet less legally/morally questionable -- than taking the code with you.
Better yet, if *you* have coded or helped with a great system, share it. If you can't share the code, share the ideas: lecture at an industry conference, talk to students, write a blog, submit magazine articles, publish a book, or whatever you can get away with; even company-internal workshops. You'll get far more information than you give, almost guaranteed. It's rewarding on several levels.
All that having been said, some of these things really do work out for the best; some of the code that was lost deserves to undergo a death/rebirth (it would stagnate and never improve otherwise), and some rare pieces should be utterly forgotten (too complex or useless to even present an effective antipattern -- the stuff of nightmares).