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.
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.
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.
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.
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
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.
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.
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?
http://beta.slashdot.org/
This space for rent.
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.
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.
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.
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
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.
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.
"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.
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.
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.