Somewhere, a voice is calling. You’re neck deep in iterators, destructors are going off all around you, and if the bloody river full of pirhana and man-eating allocators doesn’t get you, the bunker of locally scoped nuns armed with automatic variables on the far bank will ruin your day just as soon as your schnozz clears the mine field. These runtime missions always suck. “A walk in the park, Sarge. Sure.” A star shell goes off and illuminates the whole scene, and when your vision un-dazzles you get your first clear look at the far bank, which is simply crawling with the ugliest damned set of indented curly braces you’ve ever …
That voice again, faintly: “You ready for lunch?”
The haze clears. Things looked bleak there for a second. You blink. The source code in front of you still looks bleak. Lunch sounds like a great idea.
You tell a story at lunch. The one advantage of being an old fart is that you can tell some great stories. You don’t even have to make the crazy shit up; that would be harder.
I’ve been on a number of projects where it’s gone like this:
“Okay folks, the ROM is full. Put down your keyboards, it’s time to stop typing, we’re all done now.”
Team: “Yay! Ship it!”
And so final ROMs are burnt and shipped to Asia for manufacturing. The ship party is glorious; we finished three months early (the ROM was full, yeah) and customers are very happy.
Urm, well no, not really. What usually happens is:
“Oh golly gosh jiminy jeepers [not really those exact words], we’re out of ROM space. Whatever in [someone's or something's name taken in vain] shall we do?”
“Roight-O. Bring out [music: duh-duh-duhhnnn!] . . . the Code Squasher!”
“Not [duh-duh-duhhnnn!] . . . the Code Squasher!”
“Yes, I’m afraid so. If we don’t, things will only get worse.”
The [duh-duh-duhhhnnnn!] Code Squasher is about three stories tall, with a hopper on top where you stuff in the programmers, and a little tray at the bottom where you collect the . . . final product. It uses three phase power. You lure the programmers by dangling a Mac Powerbook over the —
No, not really (thank goodness). What usually happens is:
“Out of ROM space again?”
“How did you tell?”
“You’re carrying that monster copy of Compression Algorithms around, just like last month. Look, that’s not going to save us this time.”
“Another five percent and we might be able to –”
“Nope. We need to [duh-duh-duhhnnn!] … delete code.”
[look of horror] “Delete code? Doesn’t that mean we have to get rid of features?” He’s expecting Marketing Ninjas to leap down from a skylight, scream something in MadisonAvenueSpeak and whack his head off, I think.
“Look, there are probably sixteen implementations of linked lists in the system, half a dozen hash table classs, two XML parsers and any number of ways to zero a miserable block of bytes, half of them ‘optimized’. Even if you only find half of the places where people have re-written strcpy and printf, you’ll find enough space to make the next release.”
“Okayyyy. But that’s still not going to help. Maybe we need overlays, or a p-code engine, or some kind of compressed paging manager that….”
“The real disease is that you’re practically paying engineers by the line of code. Re-examine all the mini-parsers, all the places where a routine is just re-shuffling its parameters and passing the buck to another useless layer of abstraction, all the code that is in there for a rainy day that you’re just not ever going to use. Remove that junk.”
“Toss most of it away and start over.”
Systems age, just like people do, and it takes exercise of diligence to keep the fat at bay. I don’t have a silver bullet, but good organizations have people who are nosy about every single checkin. Be one of those people; you’ll learn a lot, and you’ll catch bugs, too.