Jump to content

  • Log In with Google      Sign In   
  • Create Account

Unworkable project

  • You cannot reply to this topic
24 replies to this topic

#21 LNK2005   Members   -  Reputation: 154

Like
0Likes
Like

Posted 25 June 2014 - 11:42 AM

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, 25 June 2014 - 11:44 AM.


Sponsor:

#22 Ravyne   GDNet+   -  Reputation: 7498

Like
0Likes
Like

Posted 25 June 2014 - 12:46 PM

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.



#23 gautamn15   Members   -  Reputation: 116

Like
0Likes
Like

Posted 27 June 2014 - 09:32 AM

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.

 



#24 ilreh   Members   -  Reputation: 281

Like
0Likes
Like

Posted 30 June 2014 - 02:03 PM

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.



#25 LNK2005   Members   -  Reputation: 154

Like
0Likes
Like

Posted 18 July 2014 - 09:38 AM

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.







PARTNERS