Unworkable project
- Shell scripts doing ANYTHING mission critical: check.
- Functions more than a page long: check.
- Codebase existing more than 10 years: check.
"I'm sorry, I'm afraid the cancer has spread throughout its entire body. There's nothing we can do for it anymore." - Doctor Nypyren
Why not look for a new job while you're still employed and bail out the moment you find one?
Why not look for a new job while you're still employed and bail out the moment you find one?
I didn't think of that. Actually a really good idea. Thanks.
Also, if you quit, make sure to give a couple week's notice (or whatever's required by law, if you have a law which covers this). I quit one of my summer jobs at a grocery chain once without notice and they blacklisted me from ever working there again.
Just don't let anyone at your current job know you're searching. They aren't too happy if they find out.
They'd be furious and probably lose the client. (The contract says 4 weeks notice btw). Still, it's my sanity vs the loyalty.
How feasible is it to start to rewrite the functions one at a time ?
I'd personally hit the "delete" button and blame a system glitch ...
In general I agree with getting out of there. Having said that, I wouldn't skip out too soon just for the sake of your reputation. Give it a few months.
In the mean time, do what you can do to improve your situation. Some examples:
- Document code as you go.
- Document business processes as you go.
- Split large methods to be smaller and easier to read.
- Write unit tests to ensure you don't break anything.
- Over-estimate quotes to make the time to do this.
Also remember to paper-trail everything - if a change seems risky, email them with concerns and questions and make them make the call. Make it clear that the project is difficult and dangerous. Suggest measures to limit risk, e.g. disaster recovery, backups, staging servers, QA protocols, source control everything.
How feasible is it to start to rewrite the functions one at a time ?
I'd personally hit the "delete" button and blame a system glitch ...
In general I agree with getting out of there. Having said that, I wouldn't skip out too soon just for the sake of your reputation. Give it a few months.
In the mean time, do what you can do to improve your situation. Some examples:Document code as you go.Document business processes as you go.
The existing documentation is actually pretty decent. The system is a horror, but the docs are ironically much better.
I'd personally hit the "delete" button and blame a system glitch ...
That might actually work if they don't use version control and everyone is gullible enough. Not hard to imagine considering the circumstances, but it's a stupid move.
Let me guess: AMD display driver?
Be sure to at least voice it once, however mildly, that this codebase is shit.
When you leave, kindly remind them that this codebase is shit, and is the one reason why you've never even considered staying...
Hopefully, with some luck, they'll address the issue in some way, and the "next guy" won't go #4...
Be sure to at least voice it once, however mildly, that this codebase is shit.
When you leave, kindly remind them that this codebase is shit, and is the one reason why you've never even considered staying...
Hopefully, with some luck, they'll address the issue in some way, and the "next guy" won't go #4...
Everyone involved already knows the codebase is shit. The previous three(!) developers who worked on it have all quit, and I understand them. But like I said, the client won't pay for a rewrite, because it "works". So this zombie will live to suck another day.
And what you're doing is essentially maintaining the code, or adding new features?
Out of curiosity, is the problem a cheap client? I have seen situations where the client knows their system is bad, but are unwilling to make any significant investment in it. Quick patches accrete until you get a "pearl" such as you have.
If the client is not cheap, maybe they just need the correct business case for improving/rewriting some part of the system. Reasons may include:
- Increasing maintenance costs
- Obsolete technologies
- User pain points that can't be fixed economically with the current architecture
- Increased scalability
And what you're doing is essentially maintaining the code, or adding new features?
So far mostly maintenence, but some bigger projects are in the pipeline. The dread keeps me awake at night.
Out of curiosity, is the problem a cheap client? I have seen situations where the client knows their system is bad, but are unwilling to make any significant investment in it. Quick patches accrete until you get a "pearl" such as you have.
I'm not sure how cheap they are. I assume they are because they keep on to a 15-year old project, but maybe i misunderstand. Maybe I should lobby for a rewrite. Later, when I'm not so new on the job. And if I'm still around.
"Everyone involved knows the codebase is shit" was probably an overstatement. Everyone who's wrestled with it certainly knows. My bosses have some idea, I think. The client, I don't know. The users seem relatively happy, for some reason I can't quite understand. Old habits, probably.
Why not look for a new job while you're still employed and bail out the moment you find one?
Just don't let anyone at your current job know you're searching. They aren't too happy if they find out.
Also, if you quit, make sure to give a couple week's notice (or whatever's required by law, if you have a law which covers this). I quit one of my summer jobs at a grocery chain once without notice and they blacklisted me from ever working there again.
A few years ago the group I was working with started letting people go. I worked for a large company, so I began looking for a transfer so that I wouldn't be laid off too. I found one and move my family across the U.S. After about two months I realized that the group I worked remotely with (they were in another state) had no idea what they were doing.
To this day it is the worst code I've every seen. I wasn't aware that a group of people could write such hideous and un-maintainable code. You would think, way before it got to that point it would just implode and consume itself. But somehow it just go more unwieldy. It was Java, with a JBoss server that took minutes to start, had huge XML files that serialized all the data, and could only be stopped by using the linux 'kill' command.
And the customer paid millions for it. In the span of one year, I was never even able to get the software to build, yet alone run. I am not exaggerating. The team would change the design of the system every few days, and never talk to anyone else about it. Add a few developers doing that, and a boss who was only concerned with nice suits, good watches, and climbing the corporate ladder selling snake oil, and you had a nightmare.
There was no fixing it. I found another job. I bet they are still using it, and I feel sorry for whomever has come in contact with it. I came to the hard realization that there are some groups out there where everyone is in one of two groups: those too stupid to leave, and those too stuck to leave.
Orymus3, on 17 Jun 2014 - 1:42 PM, said:
And what you're doing is essentially maintaining the code, or adding new features?
So far mostly maintenence, but some bigger projects are in the pipeline. The dread keeps me awake at night.
Find something else quickly then :) (before the storm hits)
If people in general knew how web applications are often written, nobody would dare use the internet.
If people could see all of the code I've seen in the past 20 years, nobody would dare use desktop apps, mobile devices, or consoles, either ;)
(But yeah, web applications are by far the worst)
Also, if anyone didn't already know, programming sucks
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.