Slashdot Mirror
Ask Slashdot: What Do You Do If You're Given a Broken Project?
X10 writes "Suppose you're assigned to a project that someone else has created. It's an app, you'll work on it alone. You think 'how hard can it be,' you don't check out the source code before you accept the assignment. But then, it turns out the code is not robust. You create a small new feature, and the app breaks down in unexpected ways. You fix a bug, and new bugs pop up all over the place. The person who worked on the project before you is well respected in the company, and you are 'just a contractor,' hired a few months ago. The easy way out is to just quit, as there's plenty of jobs you can take. But that doesn't feel right. What else can you do?"
http://en.wikipedia.org/wiki/D...
Long answer: Run real fast.
Seriously, don't step on that landmine. Just run away and let some other sucker be the sacrificial offering (and scapegoat).
You were hired to be the scapegoat.
document whats broken (known known), request budget to fix
document what isn't broken, but could break (known unknown), request budget to maintain
request budget to address change requests (known unknowns)
request agreement to address incidents (unknown unknowns)
now as a contractor it's easy for them to drop the blame on you even when it's some PHB who let things get to the point that they are at.
Maybe even call your staffing agency and tell them what is up before you get a black mark
The fault, dear Brutus, is not in our stars, but in ourselves.
scroll to the bottom and switch back to Slashdot Classic
You're very lucky: The person who created the project is with the company.
Question him/her!
Get an outline of how the project is supposed to work. Get broad ideas about each class, and the key functions in each class.
Then, write tests. Write more tests. Write even more tests.
In other words, you need to make sure that there's a second layer that 'knows' what the code is supposed to do and can ensure that it's still doing that.
Only after you have the tests complete should you move to fixing bugs or adding features.
Run fooorrrrrr yourrr lifeeeeee!
Also post really bad code to dailyWTF, need some more fun shit there.
First thing to do is complete a real analysis of the code and report to management with an estimate to re-write complete sections of the code. Go into it realistically and tell them up front what it will take to correct things, and why. I have been in this situation several times in my career and that has always been the best approach. There is no need to "knock" the other guys code (be positive, never the mudslinger) and done correctly, would look more like you have some fresh ideas that may not have been designed into it originally. Eother way, management wants to know what to expect and having realistic expectations as soon as possible will save everyones face in the loing term. If they feel your out of line, well, then it's time to look at all those other jobs your contemplating.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
It's a sad thing. When someone who is well respected basically gave birth to a turd, and you need to clean it up, this is not ideal, but definitely the nature of the business... the business will become acutely aware of how crappy this app is in short order without your input.
Advice: keep your nose clean. Don't complain about this person's code, but explain how the condition of the code will cost your time and energy to fix the problems as you dial in new changes. When they question you on it, tactfully explain that design decisions in the app are not entirely flexible, and changes may cascade into other areas that need to be fixed.
Depending if I'm hourly or, as a contractor getting a single payment for the job, I'd either start from scratch (hourly) or quit (single payment). If I started from scratch, I'd make sure to document the several hundred lines which of erroneous code which led me to do so, explaining that, in my hands, the only way to do it was the way I did it.
Talk to him. Plainly, just explain the issues you're having and what you're trying to get done to go over it with him. Ideally, get it in email form.
One of two things are possible here. He either did a quick "get it done" job to just get it over with really fast and move on...OR he potentially just has it setup using an approach you aren't familiar with. Even explain the issues to your boss if need be so that your boss can help to get you some of his time to go over this stuff.
There is good code and bad code...but there's also "different" code. I've seen many a developer absolutely lose their minds because something wasn't done the way they wanted it to be done even though it was a perfectly valid approach. That might not be the case in this situation, but as developers we can get a little set in our ways and a little OCD sometimes.
Keeping "respected guy" at a distance isn't going to help anybody. Absolute worst case, explain to your boss that in order to avoid breaking anything else you need him to at the very least, document how he did things. More than likely you'll ask respected guy for help and he'll have a look and either explain things or apologize. If things are tied together enough that when you change one thing, something else breaks then they are probably tied together for a reason. It would be odd for them not to be.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
Explain, with factual data, examples and clear descriptions without embellishment, the current situation of the project. Add a detailed (factual, true, sincere) description of what will happen if the problem is ignored.
Then, you need the professional maturity to know whether you are the correct person to solve the problem:
If you are, present plan with the different possibilities:
-- Restart the project.
-- Abandon the project.
-- Accept the losses and put another team to correct the project.
-- etc...
If you aren't, explain that there's a need for someone able to construct a plan with those different possibilities.
And, above all, make an effort to believe that the best solution could be to do nothing, to accept the bugs and the losses.
Gather metadata like cyclomatic complexity and prepare a few examples where changing things shows how brittle the code is. Propose structural changes and asses how much time they would take. Let them decide if they believe you and what needs to be done. The original creator will probably admit the project was rushed.
The phrase that comes to mind is "set up for failure." Don't be a fool: they dumped this job on a contractor because they knew the project was doomed from the outset. I've been there.
Which is worse: to walk off a job when you find out you've been tricked, or to stay on for the death march all the way to failure, and then get fired? (or, in your case, "contract not renewed," which is the same thing.)
My advice is to get out while you can, and be more circumspect about accepting projects next time.
If your sense of duty requires, you can discuss with your project manager why the job does not look doable any more, and see if he/she is open to major re-planning. But you should be prepared to quit the job on the spot if that meeting does not go your way.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
If you think the code needs to be refactored, come up with a plan and a proposal to do that.
It could be this individual is well respect for their ability to come up with ideas and realize through prototypes and not necessarily create long-term maintainable code.
The earlier the better!
They need to balance features vs quality vs money (aka time), and so will need to chose between a bunch of alternatives.
If you want to not look dumb, know the alternatives and be prepared to receooend one:
plus combinations.
--davecb (from a work computer)
A broken project is an opportunity. An opportunity personally and for your career. Analyze the issues, understand them and attack. Yes, you may have to work harder, but you will always have an ace up your sleeve in your next interview.
It's hard, but if you are a real Pro, you will know how to fix it, and (more important) how to fix the situation that led to the failure. Then walk away, and your reputation will most certainly follow and reward you.
If you're a good programmer, finish the project. Otherwise, quit.
Not many details to go on here, but I would handle this like any other project. Triage the problems and requirements, then work with the system owner to work them off. Be respectful to the developers who came before you. They may have been handed the same lousy situation, and done their best to work within the boundaries provided. If you are nice, they should be willing to help you understand the history of the app. They may have sacrificed robustness to accommodate some other requirement when they first wrote the system. Since you seem to have other options, then you don't have a lot to loose, and perhaps much to gain if you can bring this system under control.
Shut up, suck it up, sit down, do the work, get paid by the hour
As you have said that the person who worked on the project before is well liked and respected within the company, while you are the new guy with no good will or social capital built up in the organisation, the last thing you should be doing is forming any kind of criticism of the code or the person who wrote it.
However, if the project is truly "Broken", then the person who worked on it before will not be the untouchable God type. He may be the asshole programmer from Hell who purposefully wrote code that could not be maintained by anyone else, in which case you are his patsy and you are probably on a losing bet, because he is just waiting in the wings to swoop in, pull an all-nighter bashing away at the keyboard to rescue the company from the incompetence of the new guy, all for a measly 50% pay rise... I have seen it happen to a few contractors and it is not pretty.
The "obvious" solution, of course, is to quit and find another gig. However, the next place (or the one after that) will probably have a similar scenario, so the best approach would be to start learning to tackle the problem on this project.
That means that step 1 is to look at where YOU went wrong. By that, I mean that either your initial code analysis was incomplete (you did not check out the code before taking the assignment, or maybe you had no opportunity to check it out), or you started coding before understanding the existing structure (or lack of). Yes, you are under pressure to add value, contribute, justify your existence, and so on... but that will be doubly true next month. If you cannot make the argument in the first week/month that you need to review the existing code before making changes and adding features, then you are not going to be able to make that argument at any point. It takes a particular kind of coder to write updates to existing code without first understanding what the existing stuff does, and that type is rare, especially when dealing with an un-maintainable bird's nest of code.
If the code is already documented, verify that the documentation is accurate. If it is not already documented, then document it. The code may need to be re-factored before you can make any meaningful contribution, but right at the beginning of the project is the only possible window you will have for that kind of analysis.
If your response at this point is "I do not have time to document the code", then my advice would be to leave with your sanity and most of your reputation intact. You have already seen that coding hot, without any insight into what you are working with, causes unexpected and unexplained problems.
It seems the OP is actually asking about the ObamaCare web site.
The new programmer, in this situation, may very well be seized by the impulse to throw that old turd out and rewrite it, but a turd in the hand is worth two in the bush. Replacing the application wholesale usually leads to an expensive boondoggle that has all the bugs that the old program has already fixed and delivers a fraction of the original functionality. You hear stories about this all the time.
That doesn't mean you can't improve the design as you're adding new features or fixing bugs. Especially once you start to understand how the program works. You can isolate it into a test environment (because most of the time they're just building and deploying directly to production,) push the thing up to a version control server if they don't already do that, improve the build and deploy process and improve the design of the code in ever increasing scope until that turd has a really nice polish on it.
Or, you know, not. It's really up to you.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
1. request the project documentation.... and send it to the managing supervisor AND the former worker on the project... and send it to anyone else that MIGHT know of the project...
2. when that fails, request the specifications for the applications from the same list of people...
3. when that fails, issue a bill for services rendered... :) and offer a proposal to fix the thing (and NOT a fixed cost proposal).
http://beta.slashdot.org/
This space for rent.
Don't tear into the guy before you. Just say, "I'm sure this was built with an initial objective in mind. And it served the purpose well. The firm is doing well and expanding. I would like to know the best approach to make this product grow with it."
Then, ask the firm to define the objectives/requirements again now that you've found a *few* issues.
1.) Do you want the project to be re-built for _stability_?
2.) Do you want me to improve the _time to market_?
3.) Would you like me to leave it as is?, but be aware that extra QA will be needed.
Good Luck!
A broken project is like a broken heart. Sometimes you just have to move on.
In today's "speed of business" world, sometimes even good programmers write brittle code. And sometimes we have to deal with it. It sounds like you need to get a better understanding of this code, otherwise you wouldn't have broken it. Then you can band-aid and duct tape it, or come with a plan for rewriting, but which approach is appropriate may depend more on business than technical considerations sometimes.
Strange things are afoot at the Circle-K.
A lot of it depends on where you are at in your career and what your long-term goals are. A paycheck is a paycheck is a paycheck. Few of us get to work on our ideal sorts of projects, and even those jobs eventually go away as the company and market changes. Part of the issue is that you really don't "own" the code, in the sense that you're not familiar with it and weren't there for a lot of the decisions that went into creating it. On my old project, I could tell nearly to the line where the problem areas were and how to fix them. On my current project (which is a large, fragile, and poorly engineering Frankenstein app that I walked into), I'm kinda in the same boat as the OP. I can see a dozen places where the architecture needs to be changed and updated, but it won't happen because of budgets and a resistance to change here. Anyway, once you've spent some time with it, you'll get to understand it better, in spite of yourself. You do have to ask yourself what you're trying to achieve, though...career advancement into an architect/lead job, or just passing time until the next coding gig. I show up, do quality work, and go home to pursue my side projects at the end of the day, as I've gone probably as far as I'll go in terms of advancement. Outside of keeping my skills current and being one step ahead of the obsolescence curve, I don't care all that much what I work on during the day...so, if I were you, my big concern would be whether or not I'm falling into a code rut -- is this old tech and old approaches, or newer stuff that is still in demand? If it's something old, learn what you can, then plan an exit. If it's newer stuff, get some good experience and move on when you feel like you've left things in a good place.
You want to watch? $50/hr
You want to help? $80/hr
You tried fixing it first? $150/hr
I hope you realized which kind of software work this was going to be and priced it accordingly.
#2: Use it as leverage at review time
Things like this are opportunities, not burdens.
Development Approach:
* Make sure the source is in source control.
* Pick a semantic version number (semver.org) if there's not one already (MAJOR.MINOR.PATCH[...])
* File things in a ticket/issue system
* Link commits to tickets/issues
* Maybe even go so far as to require #[\d]+ in all commit messages.
* Explain the problem in the ticket system (DRY: Don't Repeat Yourself)
* Have links to reputable resources which describe the problems you've discovered.
* http://cwe.mitre.org/top25/
* https://en.wikipedia.org/wiki/Code_smell
* https://en.wikipedia.org/wiki/Anti-pattern#Software_engineering
* Have links to reputable resources for learning about doing good software development.
* https://en.wikipedia.org/wiki/Continuous_integration#Principles
* http://class-central.com/subjects/cs
* https://en.wikipedia.org/wiki/Technical_debt
* Write tests for existing functionality and then for all new features.
* If something is 'broken', it should be demonstrably so.
* There's no need to argue about tester competency.
* Either the test is good and passes, or it isn't.
* Pick a coding standard / style guide and stick to it. Link to it.
* Develop standards for documentation to make it easier to train new people.
* In addition to complexity/difficulty/time estimates, it can be helpful to estimate risk.
* Plan for the "Hit By A Bus" scenario.
Organizationally:
* Consider advocating for software development standards and certifications.
* Work with HR to improve hiring practices
* There are lots of great online coding interview resources.
* Require interviewees to write code in interviews.
* For isolating root cause, blame can be more wasteful than helpful.
* Make sure you notify a senior person about your concerns and intent, so that it is on file.
Is it about the money? Is it about maintaining a professional relationship? Having a steady job? Completing a challenging assignment? Learning a new skill? Working on an app that will eventually be released as a finished product instead of a never-ending series of bugs or rolling feature updates from an agile process with no end or sense of accomplishment?
Figure out what you want out of it, and then take the steps to achieve that.
That aside, I personally don't place a lot of value in seniority for the sake of seniority. That someone 'respected' worked on it means nothing at all if the product is crap.
At one workplace, I acquired a project much like you did; our three architects had all worked on it personally, over a 10 month period. It took me 2 weeks to get it running on my own machine locally - so much had been hardcoded; pathnames, machines, pre-existing sql connections with expired logins on machines only accessible from within a cluster. It had unimaginable complexity, built so that they could 'throw it over the fence' to the ops team, and supposedly let them own it, and update it for when our software changed in the future. They would only need to learn java, sql, our internal table structure (undocumented and continually changing) and SSIS too. It didn't help that the software still didn't work yet. It'd run for 2 days and then drop a 40+ gig coredump.
Yeah, I complained, and complained, and everyone just said 'make it work', so I talked to the end users and product owners, collected requirements, and wrote the whole thing from scratch as a command-line tool in about 4 hours. I had to spend 2 days making a power point presentation to demonstrate how it was functionally superior (cpu, memory, bandwidth, throughput), easier to use (2 pages of documentation), well commented and structured, had no 3'd party dependencies (so no extra $$$ for database licenses and such), and how it followed the company statement and policy (one of which was explicit; 'Do not just "throw it over the fence"').
I got a lot of positive attention from that. If recognition is your thing, that may be the way to go.
When I eventually quit that job they remembered that I got stuff done, and done well. So now I work for them in my spare time, making 3x my previous salary, on discrete projects where I call the shots and they just need something that works well without dealing with months of crap in between. So, I eventually got money and responsibility too.
Of course, your results may vary.
Find reasons, both technical and financial, to make the most professional recommendation that you can to kill the project. This means just the facts, and no name calling (actual or implied), no editorializing about the lack of quality or organization of the project's goals, parameters, or guidelines or lack thereof--although anything obviously absent should be noted. Take a moral stand, if necessary, about your resolve to not take money under false pretenses, and that continuing the project would be just that. Implying that anyone else taking money for the project, contractor or employee, would be equally doing so falsely, may be either the exact needed thing to do, or the exact most wrong thing to do, depending upon your audience.
Be honest, work with the management and keep your opinion out of it.
And welcome to the real world.
Developers are like dentists.
Every time you switch to a new dentist, he or she looks over your mouth and declares that they teeth are all in terrible shape, that the previous dentist did poor work, and it will all have to be redone properly.
Software developers are the same. They see a legacy piece of code, see only the ugly cruft and hacks, think they can do better by rewriting from scratch, but their rewrite ends up with all of its new cruft and hacks as well.Oh, and the subtle "long tail" bug fixes that had previously been fixed in the legacy codebase? None of those make it into the rewrite... instead it comes with its own fresh long tail of bugs.
Got a contract a STL phone companyl to examine a system with much the same setup; a billing system purposely avoiding all standards (naming constants "Literal-R" because literals weren't acceptable), no performs, only jumps (not spaghetti, Ramen), etc. I decrypted it's function and what it was supposed to do as well as what it did, wrote a very detailed report on what was wrong and why it was so and turned it in. I spent the last four months of the contract sitting and studying pretty much what I wanted because Mr Silver was a golden, do not touch, boy. Meh, paid very well.
If you are a contractor, and "there's plenty of jobs you can take", then you really don't have a problem here. Let's take it by cases.
1. You just don't want to deal with this app/code base/company/assignment
Then leave for one of those other jobs. That's part of what being a contractor is all about: being able to drop clients that you don't want to deal with.
You don't have to be rude or snarky about it. Give notice, complete whatever term or notice period is specified in your contract, and move on. If they ask why, tell them simply and honestly. Providing such information (if asked) is part of your service to them.
2. You are willing and able to do the work
Great! You've got a good gig, and from the sound of it, it could keep you in peanut butter and iPhones for a long time.
If the code base is a horrid mess--that's their problem, not yours.
If everything takes 2, or 5, or 10 times a long as it "should"--that's their problem, not yours.
If every time you fix a bug, the app breaks in two other places--that's their problem, not yours.
If they ask for schedules, give them your best estimates, based on what you know about the code base.
If they demand to know why everything takes so long, give them your best (diplomatic) explanation of the problems with the app. Speak only in terms of the code as it stands. The history of who wrote it and how it got that way is irrelevant.
If they decide you are incompetent and dismiss you, then you are back to case 1, above.
If they decide to cancel the whole project and terminate your contract, then you are back to case 1, above.
Part of what a company gets when they hire contractors is the ability to dump scut work on them (so that the "well respected" people don't have to do it), and the ability to dismiss them when circumstances change (w/o paying unemployment, etc.) If you're OK with that deal--the work, the scut, being low man on the totem pole, no job security--then give them the best 8 hours of your working day, cash their checks, and sleep soundly. The day you're not OK with it--the day you wake up thinking, "I *just* *can't* do this any more"--that's the day you give notice and move on.
1. Make up story
2. Restore from backup
3. Checkout
4. Wash; rince; repeat
1. Run: Quit, don't let someone else's failure become a black mark on your record.
i.e. You're a coward, not up to the challenge, nobody should hire you.
2. Coast: Just survive and let the waves wash over you.
i.e. You're a lazy fuck, nobody should hire you.
3. Double Down: It's not a problem, it's an opportunity. Tell your boss there's a major issue, but show them that you're on top of it. Make a full written analysis of the code base you've inherited; document it's strengths and weaknesses and what needs to be done to address them. Provide a task list and a schedule.
i.e. You're exactly the person people want to hire.
XML is a known as a key material required to create SMD: Software of Mass Destruction
I think that's the first thing you need to do before deciding how to react.
Did the author decide he'd created an unmanageable hack and push management to pull in a contractor to either clean up the project or simply suffer through trying to maintain it, so he could get back to focusing on his other work?
Did management rush the author to get something "usable" out the door so they could put him on another project, and you're just the mop-up crew?
It's very likely one of those two things. You could respond to either of them by simply "run, forrest, run!", or you could roll up your sleeves and get to work. If you choose to take it on, your approach will depend on why you are there. First off, trashing on the author won't get you anywhere with anyone, don't even consider it. The author may realize he made a mess, management may not. But right now the author is your best ally. Don't burn that bridge by running to management and telling them the reason it's going to be expensive to fix is because the author created a mess.
That being said, document everything, in case it comes back to bite you. You don't need to share that documentation with anyone unless necessary. It's your safety net in case the excrement strikes the oscillating unit and the author tries to blame the problems on you.
Have a private chat with the author and find out which of the two above is the reason you're there. You'll notice that in either case, he's probably very happy to have you taking over, and you should be able to easily leverage that to get his cooperation. That will make your job monumentally easier. Projects by good authors that get into this state are usually the result of inadequate planning, or a late change in requirements. The author probably had a fairly-well fleshed out plan that went south at some point, and that plan is probably not very clear to you right now. Ask about that plan, find out where the code was meant to go, why it didn't end up going there, and mosts importantly what problems did that create and how did he work around them. Those work-arounds are what's causing your grief. Knowing what they are is half the battle (that's why stuff broke when you edited), knowing why they were necessary is the other half. (THAT'S why other unrelated stuff started breaking) Get this information from the author.
At that point, you can take a very well-informed look at the project and decide if it's worth your hassle to take on. Then either take it or leave it. If you decide to bail, you can look back on your documentation and decide how much of that is necessary to justify your decision and get some compensation for your trouble. If you do decide to take on the project, discuss the issue again with the author and get their input on how to explain the maintenance costs. Even if it has to come down to "this is going to be expensive because Bob created a mess", giving him a chance to have some input on how this is addressed will help keep him in your corner down the road. If he's anywhere near reasonable, he'll understand that he's going to have to accept some of the responsibility for what he started.
I work for the Department of Redundancy Department.
You can still work at it, but given an already pre-boned project, you cannot make it fail even worse. So anything you DO manage to get out of it is just gravy.
The worst ones are the "nearly boned" projects. Jobs that are *probably* broken but with luck and hard work could work. THOSE have you sweating bullets so that it isn't failing because you're not good enough.
Excellent points r.e. "real assessment"
Also, things to consider: without knowing these, all advice offered here is less focused (and hence less useful) than it could be otherwise.
1) Who are the stakeholder(s)?
1.B) What is the stakeholders' definition of "success"?
2) What is your budget - fixed bid, time & material? (if the later, do you have a max budget or is it open ended)
3) What is an ideal outcome for you personally?
4) What is the least-sucky outcome for you personally that you would accept?
Some general advice (this applies to the excellent "real assessment" mentioned above): Whatever bad news you have for your client, the SOONER you deliver it the BETTER OFF everyone will be, including yourself. If you go heads-down a pile of crap code for 6 months and end up stuck and unable to deliver anything useful enough and timely enough to satisfy the stakeholders then things will NOT end well for you.
Also... what you think may be "bad news" may be something the client is aware of and fully expects, so don't sweat it too much. Talk to them and do some brainstorming about how to rearrange things to make success possible.
Your description sounds exactly like the only thing that I've ever been paid to do in my entire career. My job is to fix broken things and make them work. It sounds like that's your job, too. If everything were working perfectly, they wouldn't have needed to hire you in the first place. If fixing the project is beyond your skill, then perhaps moving on to a different employer is a good idea.
-Glires
I had one like this once. An electrical engineer, who was no longer with the company, wrote the original program. It was used in a manufacturing company to set registers on safety equipment the company sold. The code checked in to source control would not compile because the original "programmer" had checked in source haphazardly. There was no way to figure out which code was in the running binaries. The catch here was the change was critical. The longer this took to fix the more likely someone would die.
Decompile. Edit. Recompile. Test. Lather. Rinse. Repeat.
We made it work, and it sucked. I sat down with my boss and explained the situation and the associated risk to the company and asked for the opportunity to rewrite the app. It took a year before we started the rewrite, and I had to go through the same process two more times. Each time I reminded my boss of the issues and risks. But sometimes you have to do what you have to do. On the plus side, I got a nice promotion just before the rewrite.
When you don't have a choice, just do it. Then explain to your boss (and possibly his boss) the problem and risk to the company in language they can understand. If the app is critical or costly enough they'll eventually get around correcting the problem if you're persistent and patient. And chances are they'll remember you saving their sorry behinds when it's time for review/promotions. If they don't, move on.
1- Document every bug encountered, corrected or not.
2- Put emphasis on this project property: terrible cascading effects when anything is changed.
Whatever decision you make later, this won't hurt you and will likely help you.
Who cares if it "feels right" or not? What a silly question. If one is an contractor, paid hourly, then why should it matter if the project "feels right"? Unless the subject of the project is something like child porn or genocide, then just do the damn work and take the pay.
When I was a developer (and a contractor), and I saw a project that was a mess, I'd think, "Oh good, this project is going to require a lot of work. I should be able to make a lot of money from this contract." My "feelings" about the quality of the code were irrelevant.
I don't respond to AC's.
To be blunt, this smells like you're supposed to be a scapegoat. If a well respected individual of a company hands off a project to a contractor, something is odd. If you then notice that the project is in the process of crashing and burning, the most likely explanation is that that "respected individual" noticed that it's going to blow and that he wanted to jump ship before it's too late, i.e. before there's no way he could pin the blame on someone else. In this case, you.
Get out. Now. Explain the reasons, and that you didn't think it was necessary to check out the code because it was handed to you by such a respected and renowned engineer, who clearly must have taken over the project himself because he could never deliver such a shoddy work, and that you feel you do not have the necessary background inside the company that you could turn it into a successful product.
Get out. Now. While you still can without irreparable damage to your reputation.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
As others have suggested, talk to the original developer, document the problems and keep your boss informed. If you are a contractor being supplied by one firm to another, keep the appropriate people at both companies informed. Also, look for ways to measure the problems. First, can you run the code through lint(1) or crank the compiler options up to reveal problems? Then can you add runtime error checking or data validation code? This may help you fix things and/or be useful as documentation. Once, when working as a tech writer, I wrote a half a dozen little scripts to inspect 600,000 lines of C from a dozen programmers. Hmmm. Less than 5% of switch() statements had a default: case for error-checking. Less than 20 uses of the assert() macro in the whole code base. And so on. The programmers mostly came from a Pascal-like environment so almost none were using C idioms like if( (p = fopen(...)) == NULL) for error checking. That is OK but I found dozens of cases where they were allocating memory, starting processes or opening files, sockets or pipes with no error checking at all.
Maybe THIS guy is the problem.
Maybe the app is breaking because he doesn't understand how it works.
Everyone here is assuming that because he's picking up the project that he is the expert.
Many times companies hire the contractor to do the minor things that the employee doesn't have tme to do.
This has happened to me. I wrote a bunch of code that worked perfectly and the new guy came, slammed some code in without understanding how it worked and broke it - and I got the blame for being an idiot. I had to debug it and find the error - putting me BEHIND on my own projects just to find out I was being blamed for another's incompetence.
God I hate this industry!
Well respected means that they've got other things to do, which is why they aren't working on it anymore, and why you were brought in to the job in the first place. There's a very likely chance that this isn't his best-effort project, but rather was done as a quick-fix, or a really-fast effort. He probably never thought it would last beyond phase 1, which is why it isn't stellar code in the first place. Hey, if a contractor can stick with it, so much the better. But since you can't, and it's not your fault that you can't, it's time to rebuild it.
And contractors are perfect for rebuilding things that already exist. No need for a spec, nor for supervision. Just rebuild it. Ask for the time, and you'll get it. Ask for a quick meeting to discuss possible-future features so you build it properly this time. You'll get that too.
Enjoy.
Make an entirely new greenfield system with "many" of the features and benefits of the vaporware project, and to some degree make it extensible. Deliver it. Now offer consulting fee level services to maintain and extend it.
Simple.
Recently I had a very similar, but mirror experience. I've written a piece of complex code. Then a new guy came, looked at my code (he needed to fix a couple of things there) and decided that it's a piece of shit that could and should be rewritten from scratch in a couple of days. He failed. It's not that my code wasn't a piece of shit (it was), but there was a reason for it: that code was responsible for a very complex task and there was a severe time constraint. Most likely you have a similar code. My advice: don't blame the author. Instead, try to understand why his code is so complex. Study it, debug it, document it. Add high level tests for all possible situations. Then try to refactor the code to make it more robust and easier to understand. Good luck!
Some of us already know. You just lack courage, coward.
The correct answer is that he learns the code and how it works and then solve the problems. Express the problems in a factual way to the client.
But hey, blaming the other for writing shitty code is how is usually works in this industry - "everybody else is stupid but me" is the prevailing attitude in this industry.
Seriously. Find your best competitors, get them into the project, let them burn themselved out, leave as soon as you can.
Probably this is very bad karma.
It was called "Moodle"
First, determine what is wrong with the project.
Second, check how much time you have.
Third, determine different solution scenarios.
Fourth, discuss your findings with the "customer" or the person who gave the project to you.
Fifth, agree on a solution. Be clear that this is not a wishes come true situation.
Sixth, proceed with the agreed plan.
General rule: Document everything.
Bad projects get dumped on other teams and contractors all the time. As a regular employee, you sometimes have little choice in the matter. You simply voice your opinion to your manager and hope they can side line it. Alternatively, you move around internally and try and work on good projects.
But as a contractor, I am curious why you don't approach this as every other contractor you deal with in other fields. Ever tried to hire a home renovator, repair person...
1. Look at the job
2. If the current software is a mess, just like every other home renovator or auto mechanic, it's not something you want to work on for your regular price. You're going to have to charge more and take more time to fix various things. So make a note of what needs to change and the risks...
3. Present that to your client without judgment. Who knows why it got in this state. The superstar developer could be a superstar, but just rushed something as a prototype that management decided to put into production for example. Then see if they're want to do and if they're willing to put in the time and effort to fix it.
But just remember your status as a contractor like any other. If you renovate basements, but someone didn't do the foundation properly, the walls were leaking, the insulation was missing, someone already tried to patch it up with filler and left all kinds of bumps on the wall... you're not going to just do it for the regular fee.
Treat software the same way.
If you can't get buy in from the right folks then make sure [Style= Bold Red Flashing]When[/Style] you fail you take out as many folks as you can.
This is your time to live by the Klingon saying TODAY IS A GOOD DAY TO DIE (or stall until it is)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
First of all, don't let one bad agreement ruin the next year of work for you.
You made one mistake, not looking at the code before accepting the assignment. You've already admitted this mistake to yourself. Now take your best action to address it. I think this would be to make a proper assessment of the project.
Talk to your manager about the need for a code review with the writer. Just say he has a different programming style and you need to pick his brain (this frames him as the expert--avoiding ego issues or blame). Presumably, he has an interest in this app's continued success. When you get together with him (with your agenda of understanding what needs to be reworked... the work ahead of you) use lot's of compliment sandwiches and questions. Like, I really like your idea behind this functionality, help me understand how it works, for example, when I do this, why does this happen? Thanks. Etc... This may make him an ally.
After working with the guy and picking his brain. Make a professional assessment of the state of the project. Break it down and be absolutely real with yourself about what your job it. Code cleanup and enhancement? Complete rewrite?
You took a leap and landed in some shit. Once you have assessed the shit, the first thing to do is clean the shit off yourself (decide if this project is worth staying in--whichever you decide you must decide--time will be wasted). If you leave, remember to look at the code before accepting your next project. If you stay or give it a shot, it's time to do your best at clean off the shit from whatever is salvageable in the project (rewrite his code cleanly). Then set up a clean environment and use what you can to make a clean app.
If you are willing to clean the shit for the money you are getting, that's cool. But the project will be messy for a while and probably smell funny. It's not easy to clean up shitty code.
This guy might help... http://www.altdevblogaday.com/2012/08/18/cleaning-bad-code/
Each fix I would apply I would document and put as much information as possible. I would also document each bug encountered and give good arguements to why I need to fix it. In other word a thorough explanation so no one would need my input directly since all the info is in the report. That report would exist so the original programmer won't be able to backstab you in the back or create problems. Contractor or not that does not explain the skills of a person. It there was slacking done by the developers, his employee needs to know...If I payed a lot of money, i would expect to know that kind of thing from a contractor or anyone I pay to get the job done.
PC Gaming enthousiast that gives comments, opinions and reviews on Games. I'm just having fun with games while doing let
Try to create a decontaminated area around the bad code where you have tests, good new code and, specially, confidence on the new stuff you're building. Every time you have to touch the old codebase, try creating new code that replicate the old behavior. If you absolutely need to change the old code be sure to at least cover the affected area with many functional tests BEFORE you change anything. That safety net will make you fell relaxed and confident on your changes. Most developers really love greenfield projects but renewing an old one could be just as rewarding. If you want some hardcore insight on how to handle that, read 'Working Effectively with Legacy Code' from Michael Feathers. http://www.amazon.com/Working-...
This describes most projects I've ever worked on.
+1
Another lesson the OP needs to have learned from this situation is that every project needs a billable assessment phase, a paid evaluation. The assessment phase is needed to address the company's business and project requirements.
The first half of your question is phrased as a contractor. The second half is phrased as an employee. Mixing the two kinds of relationships will likely bring dissatisfaction.
That doesn't mean stay or leave. What it means is that if you have to choose between being: an employee or a professional contractor. Some companies have employees they call contractors which is illegal, but happens anyways.
If you want to be an employee for this company, bring the situation to your supervisor. You supervisor is the person responsible for getting you what you need to do your job. You get to choose if you want to do the job or not.
If you want to be a professional contractor, bring the situation to your client - along with one or two recommendations for action. Working with Mr Respected on this will help you sell it. If they don't want to buy your recommendations, then don't take the project.
Definitely don't leave this as a surprise till the end. That isn't good for your reputation.
Whatever you choose, don't work on deathmarch projects. They pay shti, and you will get no future references for work. They are career killers - A players know to avoid these projects. B players hire C players to take the fall on them. Don't let other people turn you into a B or C player.
The previous developer wrote the best code he can. His boss appreciates the way he handles deadlilnes, getting stuff ready everytime. Thus the boss gave the previous developer more challenging projects, and you as a contractor needs to take the easy task of maintaining the code produced. Professional programmers can handle any kind of mess. Different people think in different ways, and perfectly logical piece of code to the original developer looks like horrible mess to most other developers. No amount of refactoring is going to fix it. Your programmers need to learn to read code and understand all details of it. Even very minor issues like naming conventions are going to make it look like a mess. The programmer didn't use the naming convention you are familiar with. Deal with it. Choice of the naming convention cannot break otherwise perfectly logical code. But labeling someone elses code a mess is a big red flag. You spent two minutes looking at the code, and then you decided it's a mess. That mess is implementing important business requirements, and you don't even have specifications of what is required, much less magical crystal ball to reimplement the details. Your task is to _add more requirements_ to the code. Your task is not to break the existing code. If you can't add a feature without breaking the existing logical structure of the code, you need to STOP. stop writing code until you're comfortable enough with the small details that you can implement features in the existing codebase. Adding new features is significantly easier than "refactor all the code, then add a feature", The refactoring is not needed. It already works. You don't have enough test cases to do refactoring to the 2 million lines of spaghetti masterpiece. You don't even have the requirements necessary to rewrite the code. Stop thinking you can do it. It's impossible. Your task is to add new features. Adding new feature is very easy: you take existing empty lines of code, and replace them with working logic, implementing the requirement. It doesnt need refactoring or rewriting the whole application. Choose empty lines as the code you handle, and you never have problems with messy spaghetti code. In fact, you don't need to see the existing codebase. It's full of company confidential stuff, you can implement new features by focusing on empty lines of code.
A programmer that takes a new project, declares it broken immediately, wants to rewrite it to fix indentation and end up the same mess with different details; such programmers are toxic waste. They can't do anything. They endlessly modify already working code. So what if original programmer decided to indent his code to the right side of the editor window? Who are you to question that decision. I'm sure his text editor didn't allow proper indentation, and the design of the code follows the decisions made. You cannot understand the decisions. Programmers make thousands of decisions every time they write code. Every decision follows some logical pattern that allows a programmer to understand it. Rewriting the code just destroys the logical structure, and loses the thought process original developers used.
Ok, what is a good way to handle such projects? Don't look at the existing code. If you look at _empty_ lines of code, they're always nice and clean, ready to be substituted for something better. Replace empty lines with perfect logic that you can understand, and remember to look at the requirement while writing the code. This pattern allows writing code recardless of the original mess that exists in the codebase.
Someone hired you to take over a development that was clearly in trouble.
If it is your honest opinion that the codebase you have to work with is substandard you need to bring this to the attention of the person who pays your invoice.
You should put your case forward in relation to the codebase you have been given to work with and the issues you feel are pertinent. Make it about the code, not the people.
Your statement that "The person who worked on the project before you is well respected in the company" is a subjective one and should not be part of your argument or decision on what needs to happen to fix things.
If they dismiss you for being honest then that is their problem. You will have done your best. That's what you are being paid for.
Quidquid latine dictum sit, altum sonatur.
As this one hasn't panned out as you had hoped, you might want to consider evaluating how you approach your next contract. Rather than cross your fingers and sign up for 6 months, you might suggest to the company that they bring you on for 12-40 hours of evaluation work. Offer a reduced rate or even to do that work for free, if needed. At the end of that contract, you will provide them with your professional opinion of what it would take to complete the work they are expecting for the full contract. Break it down into schedule and price, present it to them so they can see what you're offering and how you'll be worth it. Price that contract accordingly. If you want the work, emphasize how you are now the most familiar candidtate with the work to be completed. If you don't want the work, finish your presentation explaining how you feel that as a professional, you can't in good conscience accept their contract because they would be throwing good money after bad, but would be more than happy to help them find someone who can.
This approach will tell you several things:
Don't worry about them never hiring you again. If the relationship is going to sour, it's better for both parties to know that up front rather than invest 6 months of time into it.
"You create a small new feature, and the app breaks down in unexpected ways. You fix a bug, and new bugs pop up all over the place."
When an app breaks because you fucked with it does all or even most of the blame for this rest on your predecessors shoulders?
I've seen this show many times before.. I would say it is a crapshoot as to who (old guy or new guy) was actually incompetent...usually some combination of both. A good simple *proxy* for reasoning about this is does the code handle all possible failure modes it is responsible? If shit just crashes or goes bonkers when it runs out of 'x' then you can normally expect that developer to be careless, lazy and incompetent this will manifest in all other aspects of system quality.
Otherwise it is very difficult to make any kind of determination without becoming intimately involved with the system. Sometimes you as developer just have to be more careful and suck it up as the problem space itself could be pretty gnarly to begin with and you as a nub may lack certain domain knowledge / experience.
To summarize if someone comes to me and tells me 'x' is shit and needs to be rewritten you should expect to come fully prepared to back up your claims. Introspection required.
First things first:
1. You were hired/engaged/retained because you were expected to be the best available person at your price point (hourly rate). Be sure to give the project your best effort, regardless of *any* other circumstances.
2. Recognize you may have been hired to be a scapegoat. Give it your best anyway. You might actually make it succeed under adverse circumstances.
3. Never make it personal. Always talk about the code that needs to be changed, not about the developer who wrote it. This applies to your coworkers and especially your boss. Double this for any future interviews where you're asked about why this project failed. You're an adult and a professional, not a finger-pointing little boy.
Now do this:
4. Document everything. This will take longer, but try to be explanatory in your notes (avoid accusation and snarky source code comments too). New feature breaks something? Document it. Fixing a bug introduces new bugs where they shouldn't be? Document it. See number 3.
5. Don't just document your changes, but also keep a separate diary/journal of any political machinations you may encounter related to the project. Boss seemed kinda shifty when you told him of a major problem? Write it down in your journal with date and time of the conversation and your thoughts. Original developer acted kinda smug or snooty when you asked a question? Jot it down in your journal. It will help keep your thoughts and feelings organized and be useful later when you need to reflect on it (post-mortem write-up, exit interviews, future job interviews, or even building a case against the original developer).
6. Cover your ass. Send emails to your boss notifying him of any major problems or set backs. If possible, send follow-up "confirmation" emails of conversations or meetings with your boss or other developers, etc so there are no later incidents of "he said X" "no I didn't, I said Y". This is standard project management practice, but a good habit to get into even if you are working alone on this. Send out change logs or summaries once a week to relevant parties (boss, etc). Let people know that you're doing real, honest-to-goodness WORK and that you're getting it done with no excuses.
7. Speaking of which, don't make excuses. See number 1 above.
8. If you start doing a good job, the original developer may feel threatened by your success. Ignore it, if possible. Use your journal to document any incidents if the original developer starts causing trouble for you. You may have to deal with some politics...privately documenting issues will help you later.
9. It may very well be he's too busy with new projects to even care. It may also be that he didn't want to work on your project in the first place, and took a quick and easy route to get the basic features implemented. He may even know what a bad job he did in the first place (early iterations, prototypes, etc are not always the best code) and is happy that someone else gets to take over the project. (you didn't mention too much about him in your question).
10. Finally, if you feel like the everything is working against you and you have no chance to succeed under the circumstances, take a break. Go for a walk, go to the gym, step out for some ice cream, do anything to take your mind off things for a little bit. Also good: go to a local meetup or user group (remember number 3 above if you tell someone about your project). Refresh yourself and regain your determination to get it done or fail while giving it your best. Then return to Number 1, above.
-
I spent two years in Product Management at a company where every project I worked on was doomed to fail (every product "launch" was little more than a press release and a semi-working product because my engineering resources were always reassigned mid-project, but my launch dates were *fixed* around quarterly shareholder calls. I gave each project my best effort and earned respect from my peers within the company. Because I tried to keep to the rules outlined abov
That's on you.
Posting AC for obvious reasons!!
A couple months ago I was working on a project as a sub-to-a-sub. My immediate client was an honest man, so no real worries here. The prime contractor is a cynical multinational corporation that cherry-picks projects for the easy buyoffs.
Prime blames subs for their failures for as long as they can milk it, then they just walk away from the unfinished zones. Simple math--it'll cost prime $12MM to finish this to buyoff and then they the get paid only $10MM. Walk away; leave it incomplete, and take payment for the parts where they did get buyoff. Their SOP. End customer is a large multinational automotive manufacturer.
End customer know how the game goes; they get what they can from the prime, then fire them and finish the project in-house or by direct subs. It's easy for the end customer to just not pay the prime; no buyoff; no money.
Anyhow, prime gets to the end of the easy pickins and they started tossing subs under the bus.
Honest client sat us down and said "here's the deal...you can go work directly for prime if you want; you won't be poaching my contract--you have my permission. But as for me, my team is getting out." One of the team sniffed at the high hourly rate and almost signed up with the prime. Almost.
Solution here was to walk away, and when the end customer calls directly (they did), for help finishing it, tell them in no uncertain terms what the prime was up to and we're not interested in that. When you fire the prime call us and we'll help pick up the pieces. On T&M of course.
Last month, I got a project from a different Client. I've worked for these guys off and on since late 1999.
Here is a machine; it looks like that other machine. Take the code from that other machine and make it fit this machine. We want it to do the same thing, only fifty times instead of five times.
Well, the code was a nightmare--no structure, all ad-hoc logic. The example "worked" (that is to say the non-technical manager asserted that it worked), but there was no way to duplicate it a fifty times and change pointers. This particular code was developed in a hurry to get one project out the door quickly and be done. A one-time thing that will never be used again. Which of course means some manager saw it worked once, and now they want to use it again. I know the developer of the supplied sample; he is pretty good at his job. I won't throw him under the bus. It was a T&M job, where the Client gave us NO specification when we signed up (hence the T&M). But they have a schedule to meet, and are not interested in how we explicitly did NOT promise blah blah blah... Just. Make. It. Work.
Solution there was to ask for help from my colleague. He knows where the Client has some better (more iterable) sample code, and I used that. When presenting the work-product to the Client, I explained how the better sample code was not available at the time the supplied template was developed (It wasn't).
Normally the important part is things work on their target environment. So whatever approach you take does not matter as long as things will work.
If I am thrown into a new project, I start to do a few things if they are not available.
a) set up git and port the source code to my local git repository. This allows me to work in a version controlled environment that does not require me to show my intermediate work and experiments.
b) build it and make sure things do work.
c) create a test harness even if it is just to prove the welcome page works, I can add onto it as time goes by.
d) set up a coverage report to visually how the test cases flow through the app without stepping through a debugger (if you're lucky your language supports this, most of my projects are Java based so I have these tooling available)
Provide estimates. Don't say ASAP, always give a proper time, but not optimistic estimate. I tend to pad my estimates otherwise if something goes awry I would be accountable for them. I try to estimate based on a Jr. developer who is thrown into a project multiplied by two. However, if I do finish things sooner I let them know so the plans can change accordingly. If they want things sooner, still be firm and tell them that those are reasonable estimates given your analysis. They can choose to either accept them, try to allocate more resources (ideally) or kick you out (which is better than being burnt out)
Should your team grow, let other people know how you're doing things, there's no need to document every little thing, but be there to offer. Documenting everything you know will burn you out. As far as documenting things in detail go, I do make detailed install guides to get new developers up and running. However, that document ownership gets passed to the new developer for updates and refinements as things go.
Archie - CIO-for-hire
Give the other guy an out. Find whatever excuse you can to claim that requirements for the software have changed in such a way that it needs major 're-factoring' (code for rewrite). Let those who need/want to believe that the other guy is a rock star have that out.
Then 're-factor' as much as you have to to get it working.
Then win. How? Fix 1 feature at a time. They will break other features. That's a given and it is expected. But as you fix em, use it a chance to refactor the code into self-contained well-encapsulated modules. There will be complaints about broken features. Fix em. That's expected. But don't go for quick fixes. Refactor. Refactor at every step until very little of the original code is left. And when everyone is finally sick of the problems in the code, offer to rewrite it. You'll have enough of the well-functioning components at that point that you'll be able to re-write it quickly. Look like a hero at that point. Win.
Any guest worker system is indistinguishable from indentured servitude.
Having worked on sundry application management teams (for a well known tech giant) on several poorly documented decades old internal use apps, the single best piece of advice I can offer..... ...don't try isolate yourself to try hide the fact you don't understand your application.
This is especially true when taking programming or technical business analyst lead for an AMandS team that has high turnover. If you haven't figured out what's going on within a few weeks go to your manager and tell him the documentation is weak and you are working with spaghetti code. Ask him to get everyone on your team in the same room for a few hours (or days if necessary) to discuss the project in order to bring the official documentation up to speed (possibly even a user or two of the app to better grasp business logic).
It won't answer ever question but between everyone usually the major bits and pieces get aired. Sometimes when you have conflicting narratives of what the app should be doing it also reveals previously unknown bugs and even broken business processes. That time spent upfront will be a lifesaver later on in the project.
You could simply be incompetent. If you're fixing a bug, and a new one pops up, it's possible that you're using the classes/functions/whateverajigs in the wrong way, which means that you don't understand quite how they're supposed to work. I'd suggest, maybe, instead of asking the users of Slashdot who've never seen the code the you're working on before, maybe, oh, ask the dude who wrote it.
That you chose to first go to slashdot for advice tells me something about your personality. I might be wrong, but I suspect that you feel insecure about your own position, and you feel that direct face to face communication is difficult and confrontational. You think that if you go up to the project creator, Steve (or whoever, I'm just giving him a name to personify him), he'd be taken aback by your argumentative attitude and unprofessional appearance. If you think this, I believe that the odds on this being true are very slim. Here are 2 possibilities on how the conversation could go when you enter his office or cube:
You: Hi, Steve, I'm Mark, the contractor assigned to updating your Fizawiz application. My first task is to fix an issue that got reported that when you click on 'Fiz' sometimes it doesn't respond with the right 'Wiz'.
Possible response 1:
Steve: Oh, that. Yeah, I remember someone said they had trouble with it, and when I first looked into it, I noticed that the 'Fiz' wasn't centered on the UI correctly, so it was actually hitting the 'Fiz' and the 'Fiza' button simultaneously and getting confused. What I was thinking about doing before I got moved to the Fuzabuz project was yada yada yada bling blang bloo.
Possible response 2:
Steve: Fizawiz? Oh, that piece of shit again! They should've let me write the way I wanted to, but they insisted that the Fiz do two things at once. Good luck trying to fix that, ha ha!
If you get response 1, now you've got a better understanding of his app, and some suggestion on what to look for. If you get response 2, increase your billable rate.
I've got to add, though, that it really sounds like you have some issues with social skills that you need to work through. Again, maybe I'm wrong, and I hope that you can prove me wrong by working through this with the people who best understand the problem, and not by asking opinions of random strangers on a message board on the Internet.
They like the idea, but the actual toy is not working? REWRITE IT!
It's like getting a scan or picture of a word document & people asking if you can edit it. NO I CANNOT EDIT YOUR SCAN, but OCR'ing it or retyping it is pretty much the only solution.
To be blunt, this smells like you're supposed to be a scapegoat.
I would definitely agree with that. It's the power v responsibility matrix: power with responsibility = player, power without responsibility = politician, responsibility without power =patsy (or scapegoat).
Get out.
You can. Or you can win. But if you win, be prepared to fight a fight afterwards. You'll make enemies of those who were hoping to make you the fall guy. But, then again, if you gonna make enemies who better than them?
Any guest worker system is indistinguishable from indentured servitude.
give logical reason why it's a POS,and why each issue cause other issues.
Explain to them the cost.
Use examples.
Then they will either ask you to keep on it, or to rewrite it.
Unless the point blank ask, never mention rewrite. Always let them come to the conclusion to rewrite it.
Always worked for me.
The Kruger Dunning explains most post on
Post the code in question to The Daily WTF .
THEN start looking for a new job.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
When I was doing maintenance work I would take on P.O.S.s all the time and clean them up. Usually I would find missing / lacking unit tests and set about filling those gaps. This really gets you into understanding how the code works. Then, if I found stuff that was particularly stinky; I'd move it behind and interface and set about improving upon the implementation. This is aided with unit-test coverage tools like Emma (for java), BTW. Having a Jenkins/Hudson or similiar continuous-build/integration tool really helps, too.
Rob Enderle's excellent new book: Everything I needed to know about Computer Science I learned in Marketing School
Contractors are in a unique position to ignore office politics. The guy who wrote it is respected? Who cares? He and his buddies don't determine your future within the company because you don't have one as a contractor. Assuming you want to retain the contract, explain the situation politely, and maybe privately. Worst case scenario, you work with the guy to fix things. Best case scenario, you start over from scratch and earn extra contracting dough (hopefully you're billing by the hour).
1) Audit the code with recognised Metrics Tools. Do this at the beginning and post regularly updates, ideally using a continuous integration environment.
2) Introduce Unit Tests allow you to learn the project and improve its 'Quality' in a measurable way.
3) Aggressive source code refactoring using the Unit tests as your safety net.
stop being emotional about code and get out while you can.
you can avoid the black mark if you speak with whoever you're reporting to there and explain exactly what's wrong with the app (provide specifics!) and why you're leaving (there's no way you can meet their needs in the time/budget allotted is a good reason)
you only look bad if you cut and run with no notice or explanation, if you explain why its a bad situation and why you want out at the very least they'll be more understanding, and at the best they might be so appreciative of the honesty and clarity of the situation that they ask *you* whats needed to fix it and you can re-set their expectations to something more reasonable.
Tell the original coder your problem, and suggest that you'd like to be able to fix it so that you don't have to explain to your higher ups that a bit of incompetent coding was done, complicating your efforts.
That the project is ok and you're just shit at your job.
From the ground up, a total re-write, IN MY GLORIOUS IMAGE! Ahem, it does run faster and the code is a lot cleaner looking.
Sig. Sig. Sputnik
The worst thing you can do with this information is keep it to yourself. You need to find a way to communicate the state of the code to the right people. Do it in a professional manner, but do it repeatedly.
The Information Revolution will be fought on the command line.
1) run, when you still can. Give a reason ( underallocation of resources / time / money is a good reason to quit )
or:
2) work like an idiot, save the thing, and reap the rewards.
Not being able to choose between the two reflects a misplaced mixing-up of justified self-interest, office / company politics and work ethos.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
I'd make sure to objectively evaluate the current situation in the project and the measures/resources/methods that are necessary to fix it and basically do a feasibility study. Then you can offer to whoever put you on the project to continue it along a course you staked out in the evaluation, a possibly different solution to make it better or the consequences of you continuing as originally requested/scheduled (in case that happened). If they tell you to continue, you have effectively covered your ass.
Tell whoever's in charge that you need to add tests before you start making changes to the code, to ensure that any changes you make don't break existing functionality. Ask them if there are any specifications, requirements documents, or plans you can use to decide what tests to write. If they agree, lock down the existing behavior with tests, then use the tests as guidance when you enhance/refactor/rewrite the existing code. Test writing IS development -- it's building a scaffolding around the application you're developing, to ensure that the building doesn't fall when you add another story.
If they don't agree, ask them to tell you in writing that you should not write tests first and that they accept and take responsibility for the consequences of not adding tests.
Why does everyone take his side? He is the one that added a feature and broke it. Sound like he added a feature without discussing with the original developer? When he says "You create a small new feature, and the app breaks down in unexpected ways. You fix a bug, and new bugs pop up all over the place" sounds like he was the person that hacked the code and not the original person.
If you do not document your assessment of the code, then all the problems and cost "overruns" are going to be your fault.
You will be able to "blame the other guy" for the first handful of bugs.
After a very short period, all the bugs are your fault.
You have to be nice, but firm in your assessment of the situation.
Your boss(es) will try very hard to make you accept the project and commit to adding features fast and cheap.
If you accept that assignment on their terms, you are doomed.
If they accept your assessment and your terms (rewrite all or part) then you succeed.
That. Only an a***** would try to delegate the blame.
Amen
If you're really concerned with all the credit going to the original developer, then come up with your own enhancements *AND* bundle them with (unmentioned) code fixes. Then you're the rockstar who thought up all this new cool shiz AND you're fixing his BS code. You won't get anywhere by complaining about it because mgmt will just come back and say "I Don't know why Joe is being so difficult - when Shane was on staff this application just worked."
best option in my opinion
BeenThereDoneThat. Perhaps you could say something like the following:
"I'm finding this particular source-code difficult to follow. I don't understand the rhyme or reason behind its design. I estimate it will take me X weeks of careful reading of it to get a grasp on it. If you feel you'd like to get a second opinion or try somebody else who may be better at following this particular code style, please feel free to do so. I won't take offense. My apologies for the difficulty."
Table-ized A.I.
Youre a programmer, program. Just fix it. How it got that way, whose fault it is, what-are-they-gonna-think...none of that matters. What matters is youve been given a chunk of code that doesnt work - fix it so that it does, and if that means re-writing it, then so be it.
You want to get a bad rep in this business? Worry about stupid shit like whose to blame, or complain that its messed up code (Its tooo haaard!). Or even worse, worry about the political ramifications.
and it would be the final nail in the relevance coffin ...
Attache to it a statement "In support of continued software development income, the concept of 'if it works,break it' does not need to be applied" And return the project as complete.
> You create a small new feature, and the app breaks down in unexpected ways. You fix a bug, and new bugs pop up all over the place.
In other words, practically any homegrown project you're hired as a contractor to fix. The bad news is you're in for that slimy feeling of traversing and fully understanding someone else's broken code. You're also probably in for some late hours rewriting the problematic parts. (Whether this is good or bad news is a matter of opinion.) The good news is people tend to make the same mistakes the same way, and once you fix this, you probably will get more work fixing this person's other broken code.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
"Do it and let the original idiot take the credit" is the job description. There are no good choices there, so just do the best you can for your own personal pride and the paycheck. Maybe stuff from it can be reused later.
Anyone that does programming long enough will find themselves in this situation. The trick is how to get out of it (relatively) unscathed. If you decide you're going to run from it then do it now...not next week...now. If you're going to stick it out then roll up your sleeves and get to it.
One of the things I discovered in these types of situations is that, often, bad code is the result of bad decisions not bad programmers. So keep that in mind before you start bashing the previous programmer. Do an honest assessment of where the code is now and what it will take to get it right. Document it and bring it to your manager with a plan on how you're going to fix it and how long it will take. If your manager refuses to go along with your estimates then the time to bail is now. You know where the problem lies and if you stick around you will be the scapegoat.
If, on the other hand, your manager understands the situation and goes along with it then you have won the first battle. Make sure and build in some generous time estimates. After all, you didn't build it so you very well might encounter unforeseen issues along the way. The key thing is that once you have made a commitment to a timeline make sure you can deliver on it. Trust me, management will hold you to it.
Set some milestones along the way where you can measure progress. If there is any slippage your manager will want to know sooner than later. Sooner means you have time to come up with a contingency plan. Later means you're screwed. Send regular status reports to your manager and other key people on the project. It keeps them in the loop and it covers your ass.
Conduct some conference room pilots along the way. It gives them a chance to see what you have done and, importantly, it shows progress. As a contractor it is vital that you show progress each and every week. The moment that management senses that you are spinning your wheels your ass is grass and they will bring someone else in.
One last thing - and I can't stress this enough - document, document, document. Keep all your emails, conversations, memos. If there is a change in scope then get it in writing. If that change is going to impact your timeline then tell them - in writing.
If you do all that you should be fine. All you can do is your best. Not every project is going to succeed. Work hard, be professional and you'll be ok in the end.
You can. Or you can win. But if you win, be prepared to fight a fight afterwards. You'll make enemies of those who were hoping to make you the fall guy. But, then again, if you gonna make enemies who better than them?
Had this happen to me once. It was fun when the project manager was reporting to the CTO that my work was not only flawed but that I was unproductive. That was when I threw the repository activity charts over the table. Those showed I had worked *more* than everyone else in the project combined. I followed that by throwing at the table the minutes of the regularly scheduled meetings where he previously had hands on evaluated my work and declared it as good to put into production. Then he got lambasted by the CTO.
Since the project did not perform fully to his expectation and I wasn't one of his "buddies" on the dev team I was supposed to be the fall guy. Well that enough for me I just quit. I had done all that was contracted in the allotted time. I later learned they replaced me with three people.
It was like being in kiddie grade man. Don't get in a place like that.
Your decline to take on their project will probably have more positive effect for that company, in the long run, than your attempting to salvage it and shooting your foot off. They'll be forced to either make the existing employee work on it or will be forced to scrap it and ask hard questions of the existing employee in the process.
But the premise is a stupid contractor.
Remember from the OP?
"you don't check out the source code before you accept the assignment"
In one word. Your boss needs to know what's going on.
"Feel right"? Feelings have no place in this. Cold hard facts are all that should be driving your business.
---- Booth was a patriot ----
Good luck, sucker!
http://news.slashdot.org/story/14/02/03/223204/healthcaregov-cant-handle-appeals-of-errors
Otherwise the other guy would have finished it and they shouldn't be giving it to you.
Star Trek transporters are just 3d printers.
Had this happen under a Dilbertian boss.. Other guy was a 'pet' of boss, couldn't make his project work. He told boss it was almost done 1-2 weeks of work left that could be finished off by a less senior coder. The bug he was running into took 3-5 days of run-time / crash to find.
It was multi-threaded/multi-cpu code back in the days BEFORE the Intel Core processor (we used multi-cpu motherboards to allow development of parallelism.
Problem was he had zero experience with parallel or multithreaded design, whereas I did, so I was perceived as the logical choice to find the last few remaining problems..
I didn't realize how much of a poser the other guy was -- and was naive when I agreed to finish it (as though I had a choice).
The project that ended up taking about 2-3 months due to the need to rewrite most of his code He was a new 'senior engineer by pay-grade because he'd been here on an H1B visa and had gotten a permanent residency status. He'd been a "under-the-gun" gung-ho developer while he was under the H1-B, but due this 80-100 hour weeks and desire to have our company sponsor his permanent status (which they did, all at their expense).
After he got it, he hinted he might leave, so to keep him, he was given a senior position in order to quality him for the benefits and salary range he wanted -- as well as not making him finish the code he had no idea how to do.
It took me 3 months to finish his work -- with it being fully tested. My first approach had been to optimize the code so that reproducing the bug could be done in a reasonable time. With over a 10X speed up, the bu could be reproduced in 20-30 minutes, max. It was then traced to his code not releasing locks that he'd acquired -- which seemed to work when the code was very slow.
When my boss wanted to know why I turned 1-2 weeks of work into 3 months, I pointed out the errors. He accused me of shifting blame and finger pointing. I ended up getting the 'review' the other guy should have got next cycle, while he came up smelling like a rose.
That experience and a few others like it really put me off working with other people -- as they, almost universally got stuck in their code with blame shifted to me. In no case was my code at fault -- but that doesn't stop management from blaming you.
Leave -- run, and avoid such situations at all costs. You will never come up with a positive result. The best you can do, usually is to minimize damage with copious amounts of evidence and documentation.
Read this: http://martinfowler.com/books/... Then realise that all organisations are sitting on top of mountains of crappy legacy code, and developers that can deal with it are the most genuinely valuable people in the marketplace.
If the original author is present, ask for him to walk you through the code, Ask him to explain how he structured his application.
Whatever you do, do not criticize the code, but ask him to review your proposed changes to make the product better.
By so doing, your rewrite or exorcism should get his support. All that if the original author is still available.
If he is not available, ask a second person to test his code and to advise you where to fix the unfixable. It is important to solve the political (people) problem first. And if there is a clock ticking, because you thought the work could be done with fixed cost/time, and it cant, document why. Be prepared to lose.
Leslie Satenstein Montreal Quebec Canada