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?"
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)
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.
Get over it?
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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 going to feel a lot less right when the project collapses and everyone points the finger at the fall-guy contractor.
The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
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.
Perhaps, and in that case you're damned if you do (stay) and damned if you don't (quit and run). In either case you could be looking at reputation damage.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
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?
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.
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.
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.
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.
Better known as 318230.
And worse, that could directly impact the contractor's future work prospects, if they cite how bad a job the contractor has done, even though it wasn't his fault in the first place.
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.
Do not look into laser with remaining eye.
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.
Resistance is futile. Your technological distinctiveness will be added to our own. You will become one with the morgue
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
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?
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.
I second smpoole7. As a contractor, you can't fix bad management. No matter how "professionally" you try, you're going to get blamed.
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?
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Success is not defeating the trap, it's getting the cheese.
No cheese, ergo, no success.
Go read some Machiavelli.
Q:I was listening to a CD in Grip and it sounded horrible! What's up? A:Perhaps you are listening to country music
The plutocratic collective thanks you for your amoral work ethic. Without the assistance of those such as yourself it could not grow and prosper.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.