Sign in to follow this  

Unworkable project

This topic is 1041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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. Edited by Nypyren

Share this post


Link to post
Share on other sites

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.

Edited by LNK2005

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

How feasible is it to start to rewrite the functions one at a time ?

Not feasible at all. In a perfect world, I'd rewrite the whole thing with a modern architecture (using, say, Hibernate. And get rid of all those messy scripts). But that would take months or years and require a budget that's not going to happen.
 

I'd personally hit the "delete" button and blame a system glitch ...

No you wouldn't. Not if 20,000 people don't get a salary this month because of that "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.

Very true. So far I've never stayed less than 3-4 years at one place. Job-hopping too much looks bad on the CV. Makes you look unreliable.
 
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.

Edited by LNK2005

Share this post


Link to post
Share on other sites
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.

Edited by TheComet

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
 

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.

Share this post


Link to post
Share on other sites


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)

Share this post


Link to post
Share on other sites
In a normal project, you can read the code and the docs and sort of understand what's going on. That is not an option here. I've read the docs, and they almost make sense, but the code just leaves me completely baffled. Worse, the docs and the code rarely match. There's just no way to understand it. It would take years to read up on the system, but the maintenence needs to be done today. This horror wakes me up screaming at 4AM every day. I'm in Hell.
 
If people in general knew how web applications are often written, nobody would dare use the internet.
Edited by LNK2005

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

Let me guess: AMD display driver?

Nope. It' a "swiss arny knife" application that manages salaries and a shitload of other things. It's for a major tech company that I can't name because of NDA's.

Edited by LNK2005

Share this post


Link to post
Share on other sites

Is there anyone else still at the company that understands the horror of it?

 

If so, see if you can get them all in a room with yourself, the first-line manager above this project, and their manager to demonstrate for them how bad it really is. Remind them that the last three engineers on the program quit.

 

Present a business case to management that continuing to service this project is costing them the happiness and loyalty of the employees they've hired and invested in. They may not be able to drop the project like a hot potato due to contract obligations, but at least they'll have some idea that perhaps they simply made a bad deal, mismanaged the project, and will have to eat some of today's costs incurred as a result (e.g. putting resources into re factoring that aren't being billed to the client) -- or at the very least, they'll know to not allow the contract to be extended without making it prohibitively expensive for the client -- OR -- perhaps rather than maintaining the project any longer, your company can offer a fair price on a green-field rewrite (when the client's prospects are pony up for the re-write or see their critical system EOL'd, they might become more pliable).

 

But one thing's for certain, and that's that you need to get away from the swiss-army-knife approach. I'm pretty sure I'm preaching to the choir, but those sorts of systems invariably begin to creak under their own weight. They're essentially impossible to refactor because no one dare's disturb the unknown dependencies, and basically no one person is a domain expert in all of the various aspects of the program, and hence no one is equipped to begin cutting those ties. You can't even test anything in isolation, so even if you do manage to pull things apart, you're essentially working without a net. As a result, these kinds of projects only become heavier and more complex over time, never lighter or simpler.

Share this post


Link to post
Share on other sites

There is probably a better way. Come up with reasons to get to the newer stuff. Look at timelines and see if something can be replaced in a year. You have to show them how the new stuff will have better ability to do stuff that they would want done a year later. 

 

It will take lot of lobbying and basically showing them that its useful. It is more of business undertaking and you have to show them profits to put in money. 

 

 

So I started a new job and inherited an old project that's a waking nightmare. They gave it to the new guy because nobody else would touch it. It's deliriously complex and messy. All of it is highly critical and there's zero tolerance for mistakes. Every time I almost understand some part, I discover new layers of WTF. Hundreds of tables without foreign keys. Spagetti routines thousands of lines long. Hundreds of unreadable (and of course, critical) shellscripts.
 
The system is a fractal monstrosity, completely unmanageable. Not even the previous developer, who's been working on it for 10 years, really understands it. During a meeting, when they showed me the flowchart for a single feature, I had to bite my tounge not to blurt out "please tell me this is a hoax".
 
I've narrowed down my options to:
1. Tough it out. One ugly detail at the time.
2. Wait for everything to go to hell, be fired and take up heavy drinking.
3. Quit and retain a little sanity, but risk not finding a new job.
4. Jump off a bridge.
 
#1 isn't realistic. I'm not exaggerating, it really is an epic horror. In 25 years, I've never seen anything like it. #2 is the natural consequence of #1. Every day before lunch, #4 seems like the best option. After lunch, #3.

 

Share this post


Link to post
Share on other sites

Is there anyone else still at the company that understands the horror of it?

 

If so, see if you can get them all in a room with yourself, the first-line manager above this project, and their manager to demonstrate for them how bad it really is.

 

I really wouldn't do that. The outcome (the codebase) is primarily the result of management that has absolutely no clue about what's going on. The only reason why it's still ongoing is probably because there's one guy that's been here for ages and knows all the hidden screws under it all that keep things running. So that guy is able to satisfy management even though the product is crap.

 

So the combination of clueless management and one guy (or some guys) that can satisfy management will very likely lead to give the new guy the "always complaining but not delivering" stigma if he tries to make management understand how bad it is.

 

The only advice that I can give the OP is to compare pros and cons. If the codebase is a nightmare but everything else is awesome (payment, climate, flexible times, boss,...) then it might be worth it. If the other things aren't too sweet either I'd really consider looking for another job. There's little you can do to help this situation.

Share this post


Link to post
Share on other sites
A few weeks later, things a little less desperate. Turns out that some thought actually went into the architecture, even though it's muddled by years of patching. The system is still a hideous mess, but at least I don't feel like jumping off a bridge anymore. jefferytitan's suggestion to document as I go was helpful.
 

So the combination of clueless management and one guy (or some guys) that can satisfy management will very likely lead to give the new guy the "always complaining but not delivering" stigma if he tries to make management understand how bad it is.

Exactly! I've been trying, very gently, to explain the situation to my boss. But I'm a nerd, not a diplomat. I only get responses of the type "I'm sure you'll figure it out".

 

The only advice that I can give the OP is to compare pros and cons. If the codebase is a nightmare but everything else is awesome (payment, climate, flexible times, boss,...) then it might be worth it. If the other things aren't too sweet either I'd really consider looking for another job. There's little you can do to help this situation.

The pay is pretty good. Not spectacular, but good. The coworkers are awesome. I kind of like the boss too; he's an old developer who can talk shop (to some degree). But I can't tell him what I really think of the project.

Share this post


Link to post
Share on other sites

This topic is 1041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this