"Born to Fail" projects at work

[Icarus]

Hi folks.
Once again I need your mighty wisdom
In my new job, they assined me a "stucked" project. So, they want me to integrate a legacy 30 years old code to a complete new hardware and add some new unique features to it.
Its sound easy. However code is complete spaghetti state machine. It has no documentation, there is lot's of posible dead locks and every function do someting else but its function.

So, I suggest re-writing the code and they refuse that.

What would you do guys ?

I belive that's going to blow in our faces eventually

[Andy Watson]

1. Make sure you have documented proof of your reservations about the project.
2. Get stuck in and start sorting it, secure in the knowledge that you have a never ending money earner whilst ...
3. Keeping an eye open for a better job/employers.

[Electro Fan]

1. Make sure you have documented proof of your reservations about the project.
2. Get stuck in and start sorting it, secure in the knowledge that you have a never ending money earner whilst ...
3. Keeping an eye open for a better job/employers.

  That is some pretty good advice

[EEVblog]

1. Make sure you have documented proof of your reservations about the project.
2. Get stuck in and start sorting it, secure in the knowledge that you have a never ending money earner whilst ...
3. Keeping an eye open for a better job/employers.

Yep, exactly that.
#1 isn't actually any help in the end game, but it makes you feel better. Also, make them aware of the fact you are documenting it, that alone may make them nervous enough to realise there might be very serious reasons why you are right.

[station240]

1. Install existing code on new hardware, it works.
2. Throw together a new version of the code that adds the new features, but doesn't work.
3. Spend ages "debugging" the problem, when you're actually monitoring the inputs and outputs to draw up a map of how this state machine works.
4. Finally tell the boss whenever you add some new feature if breaks, and you have no idea why any more, but offer to write entirely new code in how many weeks it would take, as you finally understand how it should work. Make sure it's a fraction of the time you wasted in 3.

[Jarrod Roberson]

First off it "works" by a very loose definition of "works" then you will do nothing but dig a hole insisting to rewrite it. In the end it will be politically futile, business people don't care about the same things you think you care about now, they never will.

The opinion/argument that "it will eventually blow up in your face" is a "slippery slope fallacy", it may also never be a problem of significant monetary value to the company. So the "safe" thing to do is not do anything until there is actually a live production problem, then do as little as necessary to limit the impact and risk.

The time for quality control concerns was passed as soon as this code went into production, that is a point of no return.

Arguing to "fix" it by "rewriting" it will just cause you way more pain and suffering in the end, even if you "win" and get your way, every little delay or mistake on the businesses part will be blamed on you and your insistent rewrite, regardless of what is actually at fault. Your reputation will suffer and you will lose the war if not the battle.

"The Grand ReWrite" never works, never has, never will, even when sponsored by the business. CYA documentation and other political stuff like that will backfire completely in most cases; for the most ridiculous illogical reasons imaginable.

For example from about 15 years ago when I was contracting; I have months of email CYA threads to a manager about a project that if done the way he wanted it done was a guaranteed failure waiting to happen, preformance was never going to meet the requirements, after like the 10th meeting I was told "just do what I want I am the boss", well I did, when I completed the project as requested in the manner requested and it didn't meet the performance requirements by 2 orders of magnitude, I brought up my CYA "I told you so 10+ times" emails, I was then blamed in a big meeting for "not doing a good enough job convincing the inept management that they were wrong, when I brought up the do as I say, that was even worse evidence that I didn't do enough to convince them, it was decided that it was my fault the customer was unhappy".

If you have to CYA yourself have already lost! You have to have CYA sponsorship and support from upper management for CYA to work as an approach.

Second, experience will tell you that everything, but especially software can be solved with an additional layer of abstraction. Wrap what you have to touch so you lessen your impact and risk to breaking it worse, move on.

30 years of experience tells me you should suck it up, keep your head down and "complete" the project as quickly as possible and train your replacement to move on as quickly as possible and be the "hero" by giving them what they want and make it someone elses problem as soon as possible.

[gxti]

I was then blamed in a big meeting for "not doing a good enough job convincing the inept management that they were wrong, when I brought up the do as I say, that was even worse evidence that I didn't do enough to convince them, it was decided that it was my fault the customer was unhappy".

It's at this point that I would start screaming as if my face were on fire.

But yes, I agree that rewriting something is a great way to waste a lot of time and end up with something with different, but more plentiful, bugs than you started with. And at the end you will have nobody for you or your bosses to blame but yourself.

Conversely, if management comes to you and says "we need to rewrite this" it's time to head for the exit. Especially if they've decided it needs to be written in a different language.

[Jarrod Roberson]

It's at this point that I would start screaming as if my face were on fire.

Why? Kind of a pointless exercise, I got paid regardless, one of the joys of being a contractor, I would never have taken any more work from them anyway. I was out of there in a short time anyway. And if you were a salary person, it would just get you fired immediately, times like this you need "to be like a cork in water", take it and give yourself time to find something better, there is always something better. Believe Me!

Brilliant thing is, shortly after this the company was sold and gutted after the owners had just sworn up and down that it wasn't in talks to sell and had no intention of selling. Guess who was the first person the new company axeman got rid of? Wasn't me I was already in greener pastures!

[PChi]

I have been in similar situations. Update your CV.

[Icarus]

Thank you wise people of the forum for showing me the light.
I'll use those tactics.

Second, experience will tell you that everything, but especially software can be solved with an additional layer of abstraction. Wrap what you have to touch so you lessen your impact and risk to breaking it worse, move on.

Yep, thats my second idea. Isolate inputs and outputs and let the existing code do the work...
They refused that idea too I don't know why

"The Grand ReWrite" never works, never has, never will, even when sponsored by the business. CYA documentation and other political stuff like that will backfire completely in most cases; for the most ridiculous illogical reasons imaginable.

I see, If I get that right. The reason is not a technical issue rather political problem

[HackedFridgeMagnet]

It's at this point that I would start screaming as if my face were on fire.

Awesome would like to go to that meeting.

"The Grand ReWrite" never works, never has, never will, even when sponsored by the business. CYA documentation and other political stuff like that will backfire completely in most cases; for the most ridiculous illogical reasons imaginable.

Big call, obviously there is no way you can back that up. I guess it is exaggerated, but I disagree. We would still be using DOS if that was true.
If the architecture is a mess then it may not be fixable. Quickest way to get it sorted out properly is to do a "Grand ReWrite". I must admit this is a hard sell, so your best bet is to bring the revised architecture in by stealth.


Isambard Kingdom Brunel once said something similar to (cant actually find the quote)

know where you are trying to get to and head as straight as possible in that direction.

[janoc]

1. Install existing code on new hardware, it works.
2. Throw together a new version of the code that adds the new features, but doesn't work.
3. Spend ages "debugging" the problem, when you're actually monitoring the inputs and outputs to draw up a map of how this state machine works.

4. Be prepared to get fired as incompetent, because the old code has obviously "worked" and you broke it/are unable to fix it in reasonable time.

Seriously, if the client/boss doesn't understand your suggestion to rewrite it and your reservations about making changes to it, then they are really unlikely to judge your work fairly either, getting you blamed for when that stinker gives up the ghost.

The earlier advice in the post #1 was much sounder ...

[janoc]

If you have to CYA yourself have already lost! You have to have CYA sponsorship and support from upper management for CYA to work as an approach..

That helps, but the point of CYA documentation is not to have ammo in the meetings with the inept managers that caused the issue in the first place (you will be only seen as an non-constructive troublemaker) but to protect your hide in the case they decide to sue for contract violation! Or, for when you have to sue for getting your payment blocked.

[miceuz]

In my new job, they assined me a "stucked" project. So, they want me to integrate a legacy 30 years old code to a complete new hardware and add some new unique features to it.

Life a shit and then you die.

How big is the codebase?

If it's clear you can't just patch it up and forget it forever, I'd suggest doing something like this:
 - start writing tests, any tests are better than none
 - if code is not testable, make it testable bit by bit
 - extract a method here, rename a variable there, try to guess meanings of "if" conditions and extract them to separate methods. split functions doing more than one thing to separate ones. In general, try to make the code speak to you as you understand it more. If you are the only person working on it right now, you can do that. When the management asks what are you doing, say you are trying to understand the code and writing tests. Show them some tests that you used to find bugs that were not known before.

Currently I'm working on a huge pile of mess written by 50 people in a course of 2 years, I can't easily do the same...

[Jarrod Roberson]

Currently I'm working on a huge pile of mess written by 50 people in a course of 2 years, I can't easily do the same...

My current "mess" is 1,000,000 lines of code written by lowest bid/lowest qualified outsourced contractors over the last 14 years. When I was interviewing for developers to build my team, I would ask them if presented with a "mess" like this how would they approach it. If they said, "rewrite it" that was the quickest way to get disqualified as a candidate for demonstrating lack of comprehension of the problem domain.

You don't "just rewrite" stuff like this, "The Grand ReWrite" is an anti-pattern for a reason, nobody changes the tires on a F1 car while still requiring it to circulate on the track at full speed, thus "rewriting" a system while requiring that it stay in production and be maintained is a futile effort that has already failed.

The only viable approach to situations like this is the "Grandfathers Axe" approach, also known as the "Ship of Theseus Paradox".

http://en.wikipedia.org/wiki/Ship_of_Theseus

[T3sl4co1l]

Way out in left field here...

...Would it be possible to emulate?  Hardware is powerful enough that even a cheap embedded controller can do real time emulation, even of "high end" processors of that age.  Compare, say, 80286 (introduced 1982) to a $3, 50MHz Cortex M1.

Even better if a backwards-compatible instruction set is still available.

Tim

[Icarus]

Life a shit and then you die.

How big is the codebase?

If it's clear you can't just patch it up and forget it forever, I'd suggest doing something like this:
 - start writing tests, any tests are better than none
 - if code is not testable, make it testable bit by bit
 - extract a method here, rename a variable there, try to guess meanings of "if" conditions and extract them to separate methods. split functions doing more than one thing to separate ones. In general, try to make the code speak to you as you understand it more. If you are the only person working on it right now, you can do that. When the management asks what are you doing, say you are trying to understand the code and writing tests. Show them some tests that you used to find bugs that were not known before.

Currently I'm working on a huge pile of mess written by 50 people in a course of 2 years, I can't easily do the same...

50.000 lines.
Thank you bro. I'll try those. One of the bigest problems there is no old hardware. So I can't even test or debug the old code.

[SeanB]

No hardware even if you have to go out on eBay and buy some? Then you really need to look carefully at the hardware datasheets and especially the errata to get race conditions and disallowed states along with the original hardware circuits and any revisions. Otherwise you are so far up the creek that no paddle will help without a lengthy rebuild of the hardware or emulation so you can actually test the original firmware works.

[T3sl4co1l]

If there's no hardware then what do they even expect to do with it?  It's not just updating a current (aging) product, nor just discontinued, but completely forgotten as well?

[Icarus]

Yeah They don't even have the old hardware schematics or PCB or the hardware itself.
They want me to figure out every thing without even testing and integrate complety arbitary new hardware.

[SeanB]

I hope you are charging wounded buffalo rates then.

We have this old code on a tape, but not............... And we want it to do XYZ on thiis unspecified non designed new hardware that is still in development and still is pre Alpha.

[Kryoclasm]

I was going to say, just do both....


A: Refurb the old code as best as possible.
B: Then if time permits, built up a rewrite.


If you can't finish B, then no one has has to know.
If you do finish B and it sucks, no one has to know.
If you do finish B and it works, keep it on the back burner until they ask you to rewrite the code.


Of course, this only works if you think it will win you a profit in the long run.

[station240]

50.000 lines.
Thank you bro. I'll try those. One of the bigest problems there is no old hardware. So I can't even test or debug the old code.

Yeah They don't even have the old hardware schematics or PCB or the hardware itself.
They want me to figure out every thing without even testing and integrate complety arbitary new hardware.

 
Oh that's far worse, it's stillborn then.
Even if you get the old software running on the new hardware, you still don't know what the inputs and outputs are.

How on earth did it get to this point ?
Did the last one die, get tossed in the bin, and then someone realises they need a replacement.
For 50,000 lines of code, writing a new system from scratch to meet the customer's requirements would be a lot more straight forward.

Update your CV and go elsewhere, this really is a failure waiting to happen.

[Icarus]

Just like Einstein said "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe"

[Stonent]

Here's a good catch-all... Any project started by someone who just took their first Six Sigma class is a guaranteed fail.