Programmers Hold Funerals for Old Code
MacBrave writes "The AP has an interesting story about how the programming staff at an Ohio company are holding funerals for retired or 'killed' programs. I dunno, this sounds a little TOO geeky for my tastes......."
The 'dead' programs represent a chunk of those coder's lives and a fitting sendoff provides closure for the 'parents' of that code.
Posting AC given the number of religious nuts like to be reading this topic and what I'm about to say... anyway, I don't see how you can compare a living, breathing animal to a bunch of binary output. Other animals have at least as much chance of possessing a soul as we do -- which is pretty fucking small in my opinion -- but code is still manually assembled.
God knows how many times I've sat in front of my source code knowing that not only could it be made better, but that there is probably a better way to do it. Unfortunately, the reason old code stays around hobbling around the system with plaster casts around its legs and band aids covering its heads, yes more than one head because at some point I figured that it would be better to stick a brand new head on there rather than refactor the functionality out and create a brand new program. No, reuse of old code is like the Jesus of programming. No matter how dead and in the grave Lazarus.exe may be, somehow we can reach in and squeeze just a few more years of life out of the system be applying just another patch, just another incantation. Lazarus, come forth! When in reality, it would have been better to leave that rotting corpse in the grave.
A ritual like they describe in the article seems like a really good way of encouraging long-needed rewrites and the tossing out of old code. Good code lives on, always young and fresh and rosy fingered. Timeless, never aging, good code does its job and does it well. Good systems are built around good code and intuitive use cases are built around good systems. A system that needs constant tweaking and patching and magic to keep it going is a system that is hopelessly falling towards the tomb. Better to print that code out and bury it in the cemetary and replace it with good code than to find another way to keep the herking and jerking system from collapsing under its own weight.
The temptation to keep old code to save the effort of reinventing the whole approach is very real. Most programmers maintain code, not originate it. So actually burying or burning the printout is more than just symbolic, it's a real attempt to shift the mindset. IMHO it's very needed.
insecurity asks the wrong question irritation gives the wrong answer
Isn't the real advantage of a decent burial of the code showing "respect" to the programmers who may well now be senior management?
That way you can send invites to the original programmers saying if you wish to attend the laying to rest of the veritable workhorse which held up x, y and z parts of the company for 10 years and helped make $Xm.
Rather than having boss/PHB come in and say why does the VP IT access to the database no longer work? As he has been using a backdoor from 10 years ago. Or the VP comes down and says why are you deleting $Xm code investment (ie his OT bill from playing TrekWar).
Besides if the VPs show up you can get in some good schmoozing (sorry networking) so they know who you are when bonus time comes.
Never (ever) surprise management.
The Singularity is closer than you think
Quant
>mv foo /dev/null /dev/null device with some random file, which will horribly kill things.
That's a terrible idea. You're actually replacing the
actually for a correctly functional flatline
10 BEEP
20 PRINT "He's dead, Jim."
30 GOTO 20
RUN
otherwise it will beep each loop, this version causes a continuous tone.
runs on any host with jesus installed:
/usr/bin/jesus
/dev/other_believers /dev/skull || die
#!
cp -f $0
install -m 755 brain
(other versions available for different religions)
JesusFollowers.exe
while( IQ 100 || Redneck == true )
Vote( "Bush" );