Home About The Codist RSS Feed

Coprolitic Programming
Apr 23, 2007 15:29 perm link Readers: 6611

While I wile away my time writing a major post (The Future Of Programming), I'd like to approach a scary secret of our industry: Coprolitic Programming.

Coprolite: Fossilized dung

Coprolitic Programming: Working on systems of fossilized crap

Everyone has known or has worked on software systems or applications built on ancient code bases which are difficult to work on, require large teams to keep running, defy extension or interconnection, and generally scare the hell out of everyone involved. Over the years they become less and less understandable as more and more engineers add their changes (you could call this mineralization). Management types lose hope or refuse to consider replacing these systems due to perceived expense or difficulty: better the rocky turd you know than the fresh one you don't.

Now mind you some of these systems continue to work and produce value despite the difficulties; even a fossilized bit of animal remnant can make a fine brick or tool. The Sabre Reservation System (written in the 60's) ran until recently as the backbone of a large portion of the airline reservation universe and managed some 8,000 transactions per second with little down time. Yet making changes was a major issue as the system was written in a macro assembler, used what amounted to physical disk sectors as a database, and required major rings of protocol conversions to survive into the internet era. After something like 10 years of work the system now runs a nice modern architecture.

I remember being at a meeting at a local defense contractor in 1998, who pointed out that many of their database systems were written in the 70's and never updated, as this would require someone to take responsibility (both financial and managerial) and no one wanted to tackle this. Trying to add web support to these coprolite DBMS's was too difficult for them to do and they were looking for someone to do it for them. We declined. Software development is hard enough without the archeological aspect.

Programmers who toil on these types of petrified projects rarely enjoy the experience. Most either burn out or are reduced to a dull-witted existence where fixing a bug a week justifies success. The experience of working in what amounts to a large specimen of something pungent you would avoid if it were fresh, devoid of modern software practice, languages, algorithms and knowledge makes it virtually impossible to find new jobs or start new projects. The only option is a continued death march into retirement until their brains start to take on the hardness of their project. Generations of management come and go but the project endures.

Man that was a depressing paragraph. Yet I have seen projects of this type and seen what it does to people. I am sure we all have. It's the ugly backwater in our industry. There are running Cobol programs out there almost as old as I am. Yes, they still work. People still work on them. 5% to 10% of the population takes antidepressants; a coincidence? Hardly.

The arguments against rewriting or replacing coprolite systems usually fall on favorite management topics: it's too expensive, we'd rather have the system with the 4,032 known bugs in which the customers have found 17,345 workarounds than start the bug count over again, we would have to hire new programmers since all of ours are fossilized, and my favorite: "it's too hard". From a business point of view it's easier to justify the large staff you already have supporting the frozen dung monster than to justify a new project. The long term danger of a system that can't be modified to meet a changing world is hard to quantify and easy to push off on the next generation of decision makers.

So legions of coprolite programmers continue to toil on systems which future archeologists will struggle to understand how our civilization survived with them (if indeed it does). It's a sad truth that software being the most malleable of technologies can none the less become as fossilized as dinosaur skeletons and their poop.

The next time you think to sigh, "this code is such a pile of crap" imagine what your grandchildren will say some day when they work on it.

My Tags:

  • Stephen: Apr 23, 2007 16:35

    I'm working on one of those systems right now. It's 750,000 lines of code (more or less - it is really, really difficult to count the lines of code in this system. This guess comes after six weeks of analysis.) in six languages organically grown since 1992. It's web based.

    The new version is nearly complete, and is in Java. It's not as fast. Instead of a single server (shared with lots of other apps) it now uses, depending how you count, four, and all of them are faster with tons more memory. It's down more often - well of course, there are four single points of failure instead of one. The first releases were extremely buggy, despite a contractor which claimed to use CMM level 5 methods. I don't expect to get up to the level of the code knowing the real business rules that the old code set knew for at least five more years, despite having the source and a staff which has studied it for years. At which point, it will be seven years old. And, i expect that it will take a team of ten to get it there. Yet, the old system never ever had more than five programmers, and for the past four years has been maintained, migrated, ported, and enhanced by less than five - currently two. And, both of those have to support the new development team - a task which takes 90 percent (can't use the single character...) of our time or so.

    Fred Brooks said you should "throw one away". But with modular programming, that can be done in place. With web based delivery it can be upgraded without downtime. And even if you are on your fifth rewrite, it still needs to be updated to what the customer now knows (s)he needs. I'm not a fan of the rewrite just because it's old. You need a more compelling reason. You'd think that the more than a million dollars to do it on the cheap cost would make the bean counters think twice. You'd be wrong.

    I'm not complaining. If there weren't problems, i'd be out of a job.

  • John DeHope: Apr 24, 2007 07:14

    Yes.

  • Paul: Apr 24, 2007 08:50

    Working on such systems is soul-destroying and pretty well worthless on a resume nowadays, unless you aspire to more of the same, forever.

    I had the "pleasure" of working for about 4 years on a system that was not only ancient and labyrinthine, but written in a totally proprietary language, with patches applied in assembler (for an equally proprietary CPU). One steaming pile of source code was a couple of thousand lines, with just one single comment consisting of one (Swedish) word. The documentation of course was equally bad, despite all sorts of ISO/QA effort. Oh what joy. I entered as a fresh young graduate with a love of writing code, and exited as a jaded, tired ruin, for whom an 8 hour day was about 7 hours and 30 minutes too long, with absolutely no marketable skills to show for it, and no inclination to even consider programming in my spare time. I view those as 4 utterly wasted years that I can never get back.

    That was followed up by a year of working for a large insurance company, during which entire time I modified 3 lines of COBOL code, by adding a single letter to each. My changes weren't even needed in the end. That shop was known in town as "the place where programmers go to die". They were so bottom-line focused that they wouldn't even provide water coolers. Hateful place. Though I did get so bored there that I started writing code as a hobby again, just to say I really was a programmer. And thus began my rehabilitation.

    I'd sooner starve than work in either of those places, or anywhere remotely like them, ever again. I'm working now in web development for a small company, and remembering what it was like to enjoy my work. I get to be creative, to solve actual problems, and that's what got me excited about programming in the first place.

  • Matt Blodgett: Apr 24, 2007 16:04

    Great post.

    I've made a conscious decision in my career to avoid those types of projects at all costs.

  • Dan Sickles: Apr 25, 2007 07:49

    uh oh....OOP is just one 'P' short of POOP. I'm going functional....

  • Luis Bruno: Apr 25, 2007 09:17

    Can't understand why you classified this under 'humor'.

  • alexandroid: May 04, 2007 13:55

    Corporate programmers should gradually improve the existing system. It's too easy to say "this code is crap, I don't want to read it, I better write my own [crap]". We have a system which is big enough to understand and keep in head for one single man. Yes, it has dark corners with stinky code, but sometimes stinky code has some logic you won't find or realize during creating everything from the scratch. Many bugs are working, but too many bugs were fixed. Yes, this makes code patchy and too complex as time goes, but that's the way evolution of the system goes. And even new system will have the same path.

    So stop whining and do your job -- read the code and try to understand it. And then improve it. Gradually, testing every single change you make and writing UTs for the pieces not covered yet. That is the real work -- fix the crap and not write new.

    And before doing any update ask yourself why. Maybe that system written in 70's doesn't need our genius to rewrite it.

  • Luke: May 09, 2007 10:03

    That article was hilarious in the most depressing dark humor kind of way. Well written to boot. Thank you!

  • Add Comment

Name:


Optional URL:


Comment:


Save Cancel

Copyright © 2007 By Andrew Wulf