EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: Icarus on April 05, 2014, 07:00:56 pm
-
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
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
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.
-
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!
-
I have been in similar situations. Update your CV.
-
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
-
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.
-
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 ...
-
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.
-
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...
-
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 (http://en.wikipedia.org/wiki/Ship_of_Theseus)
-
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
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
:wtf:
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.
-
Just like Einstein said "Two things are infinite: the universe and human stupidity; and I'm not sure about the universe"
-
Here's a good catch-all... Any project started by someone who just took their first Six Sigma class is a guaranteed fail.
-
I think the management know full well its a stinking mass of brown stuff, and you have been chosen as the scape goat when this rancid pile is flushed down.
Get out as soon as possible.
-
http://en.wikipedia.org/wiki/Ship_of_Theseus (http://en.wikipedia.org/wiki/Ship_of_Theseus)
Of course it is, by continuity. I doubt that I contain most of the molecules I born with but it's still me. ;-)
As for the issue at hand, OP, the company is paying you to do some task. Your best bet is thinking positively and creatively how it can be done within the constraints. CYA, keeping records, and a negative attitude will result in self fulfilling failure, your goal is to deliver, not to be right. My advice is to start with low hanging fruits, show some success, get their confidence, and then they will be more open for your time estimations for the more complex stuff.
My-way-or-the-highway approach does not work well with employers and it's you that will be on the highway. Be positive, show enthusiasm and find ways to delivers.
-
Assuming you want to stay, and are being well paid...
Ask as many questions about the expected (original) functionality in writing as possible. Look for conflicts with the new requirements.
If they can't answer, then it's impossible for you to complete the task
-
They don't pay me that well.
I hope that they won't fire me. Just wishfull thinking I guesss :D
-
They don't pay me that well.
I hope that they won't fire me. Just wishfull thinking I guesss :D
If it makes you feel better: When the job is so bad that you want to quit, yet the worst they can do is fire you, you're invincible.
-
If it makes you feel better: When the job is so bad that you want to quit, yet the worst they can do is fire you, you're invincible.
Few things are as potent as a regular guy with nothing to lose. When you realize you have nothing to lose, you stop worrying about how things will be accepted, or even whether or not they'll be accepted. you just do them.
No matter what kind of place it is, unless there is someone actively trying to get rid of you, results will always sway management more than proposal. giving them results will make them care a whole lot less about how you actually got it done, because the problem of getting it done has now passed; they don't have to worry about "how" anymore, and it becomes another problem that is solved.
I would ask them why there are all these restrictions on the new implementation. It would not surprise me if these things are all based on a lack of understanding of how the code currently works, or gross misunderstanding of how code works at all. Often you can find a way to reach them and get the restrictions loosened if you can find the crack in their logic.
-
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.
If they like throwing money - you could always try asking for hardware emulators. That way if they say no you complain that you weren't given sufficient resources, if they say yes someone has to get the information.
-
hmmm retain old codes, and yet add new features .... doesnt that warrant you to do anything you need to do to the old codes? after which ... it wont be pretty much just old codes anymore isnt it? ... i feel like the criteria of the project is like asking you to walk forwards and backwards at the same time ... :palm:
feels abit like this video doesnt it? *sigh*
The Expert (Short Comedy Sketch) (https://www.youtube.com/watch?v=BKorP55Aqvg#ws)
now lets add a kitten to that code shall we? hahahaha
Amen to that.
God forbid you are marked the expert! Your life just got a lot more insane.
-
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 (http://en.wikipedia.org/wiki/Ship_of_Theseus)
Ah, you mean "Trigger's broom". I see.
John
-
now lets add a kitten to that code shall we? hahahaha
After I've spend a week in compiler errors. Today I realized the famous "old" code does NOT work at all...
Now they want repairs first.... :palm:
-
After I've spend a week in compiler errors. Today I realized the famous "old" code does NOT work at all...
Now they want repairs first.... :palm:
Sucks to be you! This unfortunately is a common "no win scenario" in the software industry.
-
Just curious, what language is it written in?
-
Its written in C. The problem is that it's very flexable language. Insanity may easily reshape everything.
Such as "The International Obfuscated C Code Contest (http://www.ioccc.org/)"
-
After I've spend a week in compiler errors. Today I realized the famous "old" code does NOT work at all...
Now they want repairs first.... :palm:
That's good. That gives you time to study the code while replacing parts.
Its written in C.
That's good. There are boatloads of analysis and debugging tools out there for C code. Get every tool you can get your hands on, doing static analysis, dynamic analysis, abstract interpretation, whatever you can get your hands on. The more nit-picking the tools, the better. Because then you can show impressive statistics to your boss:
"See that tool report? We have a gazillion unresolved issues in the code. I'll get right on it. But you see, a gazillion issues, it'll take some time. Sorry.".
-
There is two ways to handle when the manager puts you on the "legacy" system:
1.) When the word "legacy" is being said, you immediately respond with "I quit". Timing is the essence. You have to be prepared for that, always.
2.) You turn Eastern-European. There was a time, everyone had a job, they could not fire you, even if they fired you, some other company had to give you a job. Breathe in the feeling. Nothing matters. Then come to forums like this, spend your day reading newspaper or books, learn about electronics. It works for millions of people.