As a developer, if you’re very, very lucky, you might get to start a project from scratch. Your own reasonable coding conventions, your own rules, your own dependency management.
Unfortunately, most of the time, developers are confronted with what is called “legacy software”. Legacy as in the pink lampshade you’ve inherited from dear great-aunt Gertrude.
Again, if you’re lucky, this legacy code is self-explanatory. Nice structure, commenting, names.
On the project I’m on, we’ve been partly lucky. We get to code web applications more or less from scratch. However, we’ve got to interact with The Portal (capital letters).
The Portal was written (from scratch, apparently) by another subcontractor, who the customer is now on very bad terms with. It manages authentication using a smart card, and has the usual menu and search functionalities such a thing has.
Now what can i say ? It’s a miracle. That it works. Just looking at the directory structure gives you shivers. And then you look at the code. It’s obscure, and it’s chockablock with hardcoding in the most unlikely places. Control structure monstrosities galore. It’s heavily intermeshed with the local (proprietary) firewalling and load-balancing device.
So this code bugs me. The problem is: i know i could do better in my sleep, but it would take me at least 15 man-days to re-implement. Time we’ve not got: it is there, so just use it and shut up.
In nearly every deployment we run into trouble with The Portal. We debug our way through it. And every time it takes a while to figure out the exact ritual to make it work.
What’s your experience ? Can you convince your customer to spend money replacing something that does work ? Do you just cope with the horror and move on ?
Depending on how interesting and/or how critical the crap-code is, I just sneakily rewrite it. Don’t ask management. Just do it. File it under ‘bugfixing’ or ‘debugging’.
Mmm, that would mean releasing to a machine i don’t have access to. Difficult to sneak in
But maybe for future cases.
I would definitely change it. It is actually what I’ve done in my latest project, to get rid of an ugly monolithic and huge portal with spaghetti PHP code everywhere.
The point to make it convincing (you need that 15 days) is to provide new features / performance / scalability in the process (or demonstrate it’s simply gonna stop working).
I’ve experienced both already, sometimes you leave it like it is and move on. Sometimes you rewrite it. I think it depends on the attitude of the customer.
Basically, you explain that the continual debugging is gonna cost more than 15 man-days.
Usually, clients understand that. If not,… let the portal crash
Y