Ask Slashdot: What Do You Do If You're Given a Broken Project? 308
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?"
Enjoy your Death March (Score:5, Informative)
http://en.wikipedia.org/wiki/D... [wikipedia.org]
Re: (Score:2)
I know which broken project we are talking about.. (Score:5, Informative)
http://beta.slashdot.org/ [slashdot.org]
Re:Enjoy your Death March (Score:5, Insightful)
It's not that bad. Results are more important than intraoffice politics, if your superiors enjoy making money.
I have been in this specific situation. In my case, the ultimate answer was to rewrite the portion of the program that was worst, mostly from scratch. We had some proprietary libraries for which we had obtained the source code. Going through said source showed that the flaws (in this case, performance drag) were well entrenched, so I decided it would be necessary to write our own code from scratch to replace it. There were no political ramifications because we no longer had a business relationship with the original company, as it had gone bankrupt, and the original code was now owned by our customer. It was on my head to succeed, and succeed I did. The performance of our software went well into the useful range and I had impressed my superiors immensely. Not only that, but about two weeks later, the other customer of our software had canceled their project, so this project that I had just brought to fruition was now the only project using our software. I saved 20+ jobs and was now in charge of our group's only project. I was a hero.
That's when politics begin to matter. Another group in the company had lost all it's customers at the same time as our group lost our other customer. That group's manager needed a project at which to work, so after arranging a public shaming of my group's manager and taking over my group, he had me moved to the basement in another building... literally... He had to replace me with 3 managers and 2 programmers and 4 operators, but then, he was able to charge the customer for 9 employees' time instead of just 1 employee's time. Now he looked like the hero and I was looking for another job. If not for charging time spent to the customer, he probably would have lost that fight.
The moral of the story is: Do your absolute best and, if money is more important in your company than politics, you will be rewarded.
Re:Enjoy your Death March (Score:5, Insightful)
So you were demoted to a basement position and someone else, who had no part in the software you wrote, reaped the benefits and became the company hero for your work. How exactly were you rewarded?
Re:Enjoy your Death March (Score:5, Insightful)
Success is not defeating the trap, it's getting the cheese.
No cheese, ergo, no success.
Go read some Machiavelli.
Re: (Score:3)
Success is not defeating the trap, it's getting the cheese.
No cheese, ergo, no success.
Exactly. Like other engineers too often I find myself focused on fixing code which sometimes can't be fixed in the allotted time, or trying to explain to management why the thing is broken. Success may involve "managing up" and diplomatically extricating yourself from blame for the situation, more than finding a way to make the project work.
Re:Enjoy your Death March (Score:5, Insightful)
Summary of your story: Do your best, and you'll get screwed over by politics anyway.
To the original question: If you rewrite the code and make it a huge success, the original author will get all the credit. If you fail because the code is a stinking pile of crap, you'll be blamed, not him. Welcome to the corporate world.
Re: (Score:3)
Depends if you just sit their quietly.
Personally I grew tired of doing that and nowadays I'm just blunt to management. If something is shit, I tell them it's shit, and I use the word shit. If they don't like that I can go work elsewhere where they actually want to know if something is shit so they can act on it. Nine times out of ten though, they are okay with being told the cold hard truth, providing you can justify your reasoning as to why you think it's shit and offer them a solution as to what needs to
Re:Enjoy your Death March (Score:5, Insightful)
Here is the problem.
1. The poster is judging the person by his code. We all write code, and in a few years we look back and go, what the heck was I thinking.
2. Most home grown programs grow organically, so there isn't a strong strong infrastructure to it. This doesn't mean the maker was unskilled, or a bad programmer.
3. It was a learning process at the time.
So this is what you need to do.
1. Add what you feel is a good infrastructure to the project. It isn't that his code is bad, but we now have a newer way to do this, so it more manageable.
2. Look for what is good. Even in bad code there is often a lot of good parts to it. Take advantage of it, and be sure to keep it.
3. Document your changes, and explain them.
The guy is well respected in the organization, that is fine, you should respect him too. Being that you have been hired to maintain his code, means he doesn't want or cannot be bothered with it any more. That said, it is your baby now and you will need to raise it your way.
Re: (Score:3)
1. Start writing new automated tests for the existing features of the application.
2. Run them against the original, unmodified code.
3. When your changes break the tests, work out what *you* did wrong, before you commit your changes.
How can you get anything done if you don't find out quickly that you broke something?
Re:Enjoy your Death March (Score:5, Interesting)
No shit. The person is employed as a coder. Would you judge a surgeon by his poetry?
We might do that in the first year of our career, or maybe six months into a new language, platform or type of app. If you're doing it regularly at a later stage you're an utter flid and should go and do something else.
I should respect someone because he knows the right butts to kiss? Don't think so. I've cleared up a fair few messes made by "well respected" people, and part of that process was resetting their reputations to something more aligned with reality.
Short answer: Run. (Score:5, Funny)
Re: (Score:2)
Re:Short answer: Run. (Score:4, Insightful)
Get over it?
Re:Short answer: Run. (Score:5, Insightful)
It's going to feel a lot less right when the project collapses and everyone points the finger at the fall-guy contractor.
Re:Short answer: Run. (Score:5, Insightful)
You don't work for that company directly. 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.
Re: (Score:3)
> that could directly impact the contractor's future work prospects, if they cite how bad a job the contractor has done
They're going to do that anyway, whether he stays to completion/collapse, or quits now.
I say quit now, find something else right away and let it blow over. It may not seem like it right now, but it WILL eventually blow over. Get another successful project or two under your belt and the one bad project won't glare too badly on the resume.
Re:Short answer: Run. (Score:5, Interesting)
I was given a project that three (!!!) previous developers had worked on, but obviously none of them finished.
The code mostly looked okay. And it passed all the tests.
But that was misleading. The way the code was written, it was hard to read. AND it had sloppy formatting. Those are not necessarily signs of bad code, but they can be bad omens. I should have heeded them.
Turned out the tests were poorly written. And whenever I made even little changes, things broke all over. To top it off, rather than giving me time to refactor the old code, they kept me too busy making trivial visual changes.
THEN, the kicker: they suddenly hit me with a deadline of 3 days! I could hardly believe it. Even though with a lot of effort I had finally gotten it basically working, it was nowhere near ready for production. I told them this; they didn't listen.
So of course when it wasn't ready by the deadline, they blamed me. Which is just plain dumb. I didn't really care at that point... I was a contractor and I had seen what a rotten place it was to work. I was happy to bow out. Which I later found out was the same attitude as the three developers before me. They were happy to be out of there.
Re:Short answer: Run. (Score:4, Insightful)
He says in the summary that quitting does not "feel right".
If I conducted my business based on what I deemed to "feel right", I would probably never leave my house.
Re:Short answer: Run. (Score:5, Insightful)
The plutocratic collective thanks you for your amoral work ethic. Without the assistance of those such as yourself it could not grow and prosper.
Re: (Score:2)
At the long run (after you run away into a safe place), develop a better feeling of what's right or wrong.
Re: (Score:2)
Agreed. Run, Forrest, Run!!
Re:Short answer: Run. (Score:5, Insightful)
If you're not going to wimp out and run, then man up, confront the situation, and fix it. Regardless of whether the original author is well-respected, you need to expose the problem. You don't have to be an ass about it, just go to the original author and ask him why its in the state that it is, more often than not he was under deadline to get it finished and cut corners. Worst case scenario, he thinks he's a rock star and can't believe they hired a dunce (you) to replace a genius (him). Or just tell your boss that the existing state of the code is hindering progress and things need to change, don't even mention the original author. Figure out what you have, what it needs to be, and plot a course to make he necessary changes to get it there. Inflate estimates to adjust for the added complexity and if anyone questions your estimates, tell them exactly why it will take you that long (which may include "I haven't touched that code yet and am not familiar with the potential side-effects" or "the architecture is so fubar'd that I'm going to have to refactor").
But whatever you do, absolutely *do not* bitch and whine about it. No one likes a whiner and it will just make you look like an amateur. Always remember, the problems of writing and maintaining software are hard and not always technical, you're paid to solve them. There are already too many amateurs making good money to create more problems than they solve, don't be one of them. And always remember that no matter how smarter you are than everyone that came before you, cleaning up their shit is ultimately your job. Deal with it.
Re:Short answer: Run. (Score:5, Informative)
I think this is good advice, and having been on the other side of this issue, I think it's important to note the worst case scenario may not always occur here. I had to write an incredibly large application on an absolutely impossible deadline, in a programming language I wasn't incredibly comfortable with using, and there weren't any "objections" allowed, given the setting. I was young, I wrote it, and accepted what I was doing was crap, but I had to cut every corner imaginable just to get it done. Fast forward ten years, the company wants to sell the application to others, because, while it's poorly done (IMO), it does everything desired and people are still looking for that type of software in our industry. Someone else was hired to review/rewrite/refactor. The guy who was hired eventually came to me expecting he was going to be the fall guy (hell, he may even have posted here), and when he brought his (incredibly well done) analysis of what was wrong, I told him he was absolutely right, he shouldn't be afraid to say it openly, and I'd be happy to help him understand the "guts" of what was trying to be accomplished.
Long story short, while I guess in most times it really is a political slugfest about to happen, sometimes it's that the person who did the application, rock star or not, was put in an untenable situation and did the best they could with it and is well aware it is garbage, spaghetti code that went through 100+ changes of scope due to poor project managers. It doesn't mean that person necessarily is going to hate you for it.
Re: (Score:3)
One of my CS modules in final year was "Software Maintenance". For the coursework, we were given the department's exam results tracking software, which was written in Perl, and asked to plan how we would improve performance and add some new features.
IIRC, I think my group recommended rewriting it from scratch in either Java or C#, and I think we got full marks...
Re:Short answer: Run. (Score:5, Insightful)
Rather then going and asking the original developer why it sucks, explain to the developer that you have been assigned his project.
If he is a "rockstar " then he will lord it over you and you know to run.
If he knows that it sucks and tells you, then you likely have an ally in your quest to fix the app.
Re: (Score:3)
That plus some advice. Do your due diligence first. Blindly accepting a coding project without at least taking a cursory look at the code isn't very wise.
Re: (Score:2)
Re: (Score:3)
Recode from the ground up, congratulate the well respected member of the permanent team on taking the app as far as he did - explain the time required to add the requested functionality - if they don't like your time estimates, find another job.
If you add your signature to the broken code, the steaming pile becomes your legacy, not his.
If you provide a good replacement without trumpeting what an incompetent ass the previous author was, nobody is really going to know or care that you ditched all his code and
You were not hired to finish the project (Score:5, Informative)
You were hired to be the scapegoat.
Re: (Score:2, Interesting)
Or, perhaps, you were hired to find a scapegoat. Honestly, who cares; they need the project to work, so make it work.
The project is yours. Guess a rewrite timeline, send it to your boss, and get to work. While they bicker on it, send them updates. If you are going to get fired, it was going to happen anyway; you can still do good work in the meantime.
Re:You were not hired to finish the project (Score:5, Insightful)
If he makes it work, the original "respected" designer will jump in and claim all the credit.
If he doesn't, he, as the scapegoat contractor, will get all the blame.
No-win situation. Leave now.
Re: (Score:2)
If he makes it work, the original "respected" designer will jump in and claim all the credit.
If he doesn't, he, as the scapegoat contractor, will get all the blame.
No-win situation. Leave now.
If you want to be unprofessional and only ever want to take easy jobs, fine that's a route you can take. Other times you can work like an actual adult and solve the problems.
Re: (Score:3)
> Other times you can work like an actual adult and solve the problems
I don't know the details in this case, and neither do you. But trust me, it ain't always that simple.
Years ago, back when I was still doing the contract programming gig on the side, I took a job for a major multinational. This was a relatively simple concept: write some software that read the AutoCAD files for the wire numbers, and then print heat-shrink labels to go on the wires. Sounds good, right?
First strike: it was done in Visual
Re:You were not hired to finish the project (Score:4, Insightful)
On lesson I have learned the hard way: if you insist on tackling it anyway, keep records of EVERYTHING. All emails, all memos. Even record conversations if you are where/when you can get away with it, and if you aren't in a position to do that, take good dated notes. Then when all is said and done if they try to blame you, you can prove it wasn't your fault.
I have worked as a contractor for some very bad managers. Of course I did not know that going in. But later when they tried to blame me for problems I could point to an email, or a Skype conversation I had saved, and say "Uh... just no. That's not what really happened. See?"
And it really pisses them off when you do it in front of other people. But you might as well, because they're trying to shaft you anyway, right?
Re: (Score:2)
If he makes it work, the original "respected" designer will jump in and claim all the credit....No-win situation. Leave now.
Well, that all depends really. Is he receiving a paycheck in the process?
Re: (Score:3)
He's a contractor, why does he care if the original designer gets the credit? If his manager is any good he may already know that this is a steaming pile, if an outside contractor can fix something without pissing off the original designer he's going to be a happy camper. If the contractor can enlist the assistance of the original writer to fix it, giving him an actual reason to claim some of the credit and an incentive to share, then everyone wins.
Re: (Score:3)
> He's a contractor, why does he care if the original designer gets the credit?
Bingo. I generally do my best to make certain that the permanent workers get credit where it's possible to do so. If there's a permanent worker who is completely incompetent, then I'll simply refrain from praising them to management. Praise is not a zero sum game, bosses are not usually idiots, and a cordial work environment where people are happy to see and help each other is worth its weight in gold.
It's simply self-in
Re: (Score:3)
My advice: act like a grown-up. They're paying you to code new features? Code new features. Paying you to fix bugs? Fix bugs. If you have the time and resources, refactor and fix existing code as you are able.
This is the only response you need. Like I once told a previous employer when I was given a shit project, "Hey, I don't really care what you want me to work on, but I do want you to know that this project is doomed and here's why ... "
Re: (Score:2)
I'd be more inclined to go this route...if hired as a contractor, then self-evaluate whether your contract lasts longer than it would take to rewrite. If it takes longer to rewrite, communicate the problems and just triage as best you can unless they offer to extend the contract. If you have the time, refactor as you enhance so that you balance a rewrite with getting features completed.
Re: (Score:2)
"they need the project to work"
Do they, Jane?
http://www.youtube.com/watch?v=SgAvehEDHYY [youtube.com]
Re:You were not hired to finish the project (Score:4, Insightful)
It might be worth doing some digging around the company, though. What relation does your boss have with this app and with the previous developer? What is the history of the development of this app? If this is a doomed but high profile app, the scapegoat theory would seem to hold. But if your boss wants the app to succeed and has no reason to be afraid to potentially piss of this darling developer, then it's worth talking to him, especially if he knows a bit about software development. Explain the problem and provide estimates on what it takes to turn this thing around. That's what I would expect a contractor to tell me if I hired him with honest intentions.
Re: (Score:3)
Yes, and present as a "go -no go" choice and let him make the call.
If he says no go, you can move on with no consequences. If it is "go" and it fails, you documented why it was in trouble and what the risks were.
Re: (Score:2)
Maybe. Maybe you were hired because you are disconnected from the company politics and culture. Talk to the customer and the previous developer (really bad sign if they discourage the latter). Get an idea what went wrong and negotiate your terms based upon avoiding the same pitfalls.
Some of the most interesting projects I've worked have been ones that the locals couldn't solve because they had to live there after the dust settled (see sig line).
One reason companies hire contractors for jobs like this is v
Re: (Score:2)
One reason companies hire contractors for jobs like this is visibility.
Another reason they hire contractors for jobs like this is to get a fall guy. "The code worked before we hired the contractor, now it doesn't work, obviously the contractor is to blame."
apologies to rumsfeld (Score:5, Insightful)
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)
Cover your ass and vote for a IT union (Score:3)
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 (Score:3)
Write tests. Write more tests. (Score:5, Insightful)
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.
Re:Write tests. Write more tests. (Score:4, Informative)
Too bad the poster here was AC and didn't get modded up, because he is absolutely, positively right. All the people here who talk about code analysis, etc., are completely missing the point. Simply ask, publicly, for the test cases showing a positive path, and the test results. If they can't be provided, go back to management with the statement, "I don't understand why, but I'm not getting the same results as the previous engineering team did. Before I add any features or fix any bugs, we need to baseline what works and what doesn't.
I inherited a project like this in exactly the same circumstances. It was a dangerous time for me at the company, and the previous engineering lead did make some questionable accusations, but by keeping it non-confrontational he basically ignored me and went back to what he was doing. Management eventually saw that I was dedicated to getting things working so long as they let me do what needed to be done, out of their own self-interest.
I give a lot of credit to my product manager, who helped me navigate the political waters on that one (which included being called an incompetent liar to my face by the previous engineering lead). It worked out great for me in the long run.
Make a real assesment (Score:5, Insightful)
Re: (Score:3)
Re:Make a real assesment (Score:4, Informative)
Also.... Re:Make a real assesment (Score:5, Insightful)
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.
Suck it up (Score:5, Informative)
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.
Re: (Score:2)
There is no evidence to support this hypothesis. Unless the OP had explained this to be true, I would not jump to this conclusion.
Re: (Score:3)
You know, I question if that's the case.
I've seen several instances where someone throws together a proof-of-concept and then says "see, solved problem, the rest is an exercise for the reader". In fact, I once got something thrown at me by a VP who had knocked something together with some cheap hacks, string and tin-foil. In practice, what he'd done worked on a single demo system but couldn't remotely be made to work in a real system.
Then you get into the problem and discover that so many naive assumptio
Re: (Score:2)
Yeah, that's at least a strong possibility. Both of my software jobs featured a highly celebrated "hero" coder whose primary skill was quickly smashing out a thousand lines of unreadable code per day. If management asked for "X", he (both of them) would just bulldoze the codebase and everyone else's work to the ground to deliver that day, and was much beloved for it.
Depends (Score:2)
If the "well respected guy" is still there (Score:5, Informative)
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.
Re:If the "well respected guy" is still there (Score:5, Insightful)
Further, if it's case 1 (a quick "get it done" job to just get it over with really fast and move on), then you need to take the proper tone to set up an environment for you to complete the task you were brought in to do. What I'm talking about is portray the software in a positive light - that it is efficient, single-purpose, quickly developed, etc. However, for those reasons it isn't very extensible, and you're going to need to lay some groundwork and framework to facilitate the enhancements they require. What I'm presuming you're lamenting is you don't have the time or bid too low for the amount of work required. You need to communicate to them that you will have to reorganize a significant amount of the existing code in the process. Be sure and state the advantages (IE what they're getting for their extra money), which will be streamlined future enhancements, and importantly, more efficient maintenance of the software from here on out.
I've been in this situation a number of times, and every time the higher-ups had an appreciation for the extra work required to lay a good groundwork and I was able to proceed in the manner I recommended even if it took more time. Another way to explain it to a non-technical person is that software is often built very incrementally and piecemeal, and that can result in a hodgepodge of code over the years, and every now and then it requires a good reorganization and consolidation of redundant parts into reusable libraries. Usually they understand that general concept, because it's true of most physical, real-world assets as well.
Re: (Score:3)
+1
The right answer is almost always to communicate and then communicate some more. Use both informal and formal channels, staring with the informal ones so no one is blindsided, but with the formal communication ready to go (so whoever you talk to doesn't have an opportunity to blindside you). In the informal communication, be clear that you are going through formal channels as well, in fact it's probably a good idea to approach the original dev and whoever else is appropriate with something "I have writt
Re: (Score:2)
Not a software developer myself, but I worked closely with a group of them for years....
I'd say MillerHighLife21 is absolutely right. Any developer who actually has *some* level of pride in his/her work will usually be happy to explain the code to you, if you've taken on working on their original project.
Someone else posted that you "can't win" because even if you fix it completely, it's the original author who will come back and take all the credit. That could well be true, but let's face it.... you're a
Write a comprehensive dossier on the situation (Score:2)
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 are
Don't take the fall (Score:4, Insightful)
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.
Plan and proposal (Score:2)
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.
Professionalism (Score:2)
Re: (Score:2)
... or : the original dev, or a manager in the company scoops it up as their win ?
Like Any Other Project (Score:4, Informative)
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.
Step one, do not criticize. Step 2, document. (Score:4, Informative)
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.
Nice cloak post (Score:5, Funny)
It seems the OP is actually asking about the ObamaCare web site.
Re: (Score:2)
Ah, thought he is talking about one of my apps
No, she isn't.
All Programs Are Like That (Score:5, Insightful)
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.
Step 2, go back to Step 1 (Score:2)
+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.
Restate the objectives (Score:2)
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
A broken project is like a broken heart (Score:2)
No Easy Answer (Score:2)
Car maintenance price list: (Score:4, Insightful)
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.
Re: (Score:2, Funny)
You want status reports? $200/hr
You want to ask questions? $300/hr
You want detailed discussions? $500/hr
You want to be treated like a human being? $800/hr
#1: Ask for a raise (Score:2)
Things like this are opportunities, not burdens.
Decide what you're getting out of it (Score:2)
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
mercy killing (Score:2)
Developers are like dentists (Score:2)
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 h
Been on that contract (Score:3)
Problem? What problem? (Score:2)
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 a
Three options: run, coast or double down (Score:2)
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
find out why you were hired (Score:5, Insightful)
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.
This is why poeple call their jobs "work" (Score:5, Insightful)
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.
Two points (Score:2)
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.
It doesn't "feel right"? (Score:2)
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
May not feel right, but it's the right thing to do (Score:2)
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,
Instrument the code (Score:2)
All Projects are Broken by some Degree (Score:3)
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.
Document and Charge Appropriately (Score:2)
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 i
Fail In a Glorious Manner!! (Score:2)
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)
Whos fault is this really? (Score:3)
"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.
Notes from the trenches.... (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Seriously you should never allow yourself to be pushed into doing crap quality work. By doing what you did, you just undermined your own professionalism and reputation badly no matter what the actual reason. People will always quickly forget that you got them out the shit at the time, but bad code with your name on it will be there for all to see for ever.
I understand you were on a deadline, but you should have instead pushed back when you got given the task and told your boss that it wouldn't be possible t