.. of code.
The code I usually work on has been actively used and developed for the last three years. That's really not unusual for what is essentially a very elaborate website with a massive transactional back-end (all written in Java) that talks to many different ticketing systems. It's a very complex project. I often find myself re-writing code because something has changed that facilitates better, more efficient or just simpler processing -- sometimes that something is my own logic and knowledge padded by the additional experience gained since the last time the code was touched. I often find myself wishing I had the time and schedule flexibility to re-write much larger and more complex parts of the code, but as we all know, wishful thinking is just that and schedules are often unforgiving. Today was one of those days.
A code-base, like the one I just described, is really like a big, elaborate gum ball.. when it first starts out it's all smooth, shiny with an underlying sweetness that just begs to be enjoyed. As time goes.. that changes, it gets chewed up, sweetness goes away and before long it just looks like a chewed up, sticky, used-up piece of gum. Other coders add their own tidbits.. and before you know it you have one, gigantic, messy, sticky ball composed of patched-on pieces that doesn't even remotely resemble the sweet and juicy round thing it once was.
I have a theory.. any project that's been actively developed for more than three years needs to be scrapped and started from scratch using the experience gained in building the original code-base. Much like a stepped-in piece of used gum scraped off the bottom of a shoe.
Now isn't this the stupidest analogy ever? It was so bad I just had to blog it ;)
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/1231
And yet that's exactly the kind of thing Joel would argue against. Eek!
#If you haven't read it recently (or, God help you, haven't read it at all), run, don't walk, to the Salon archives and read "The Dumbing Down of Programming".
http://archive.salon.com/21st/feature/1998/05/cov_12feature.html
http://archive.salon.com/21st/feature/1998/05/13feature.html
"Code and forget; code and forget: programming as a collective exercise in incremental forgetting."
This is why rewrites never work. "The expertise gained in building the original" isn't in the heads of your programmers; it's sitting in the original code, long since forgotten.
#"The great, sticky balls..."
Ya know, you always have a better one involving balls..
"Weblogic sucks balls"
Mark is right. I've done several rewrites on several projects and in most, rarely any if anything is the original code base improved upon with its ideas and what is learned..its gets incrementally better, but not better enough to validate a whole complete overhaul, instead of just adjusting the existing code..
#Check out:
http://www.laputan.org/mud/mud.html
for a somewhat related discussion.
Here's the abstract:
---
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?
---
Ayup. The common terminology is "Big Ball of Mud", and if you have the time to spend, you will probably want to read the essay. http://www.laputan.org/mud/mud.html
Rewriting entirely from scratch is almost never as clean as one thought beforehand though. Most problem spaces are not tidy and clean-cut, so the code that addresses them can't be either. Likely, every time you start from scratch, you have to solve the same problems posed by a messy problem space all over, and you may reach different limitations, but you will reach limitations nonetheless.
The old code, crufty as it may have become, has been debugged and solves certain problems well enough to be depended on. That is rarely something you should throw away. Extreme Programming advocates to Refactor Mercilessly instead.
chromatic's "Myths Opensource developers tell ourselves" ( http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html ) has a tidbit on this, and while your codebase is not open, a lot of what he writes applies equally to closed source projects as well.
#Well, so much for my idea being an original!
Guess I have a lot of reading to do.. wish I had more time.
#I think it's a pretty good analogy. :-)
Btw, I stumbled upon your blog whilst mindlessly roaming the web. Always fun to meet another girl as geeky as myself. :-)
#Java is more than 10 years old now (that's including when it was known as Oak) should I switch?
Another question: what do you think about Stallman's opinion that Java should not be used in open source projects (If I got that right...)?
#