You have two weeks to...
-
Discretely call up the new company and tell them how poorly he documenents code and that he leaves work unfinished and has no intention of finishing it. Hopefully that will make the new company think twice about hiring him and that will give you more time to make him document his code. :-D
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
and get you into one hell of a lawsuit if he ever finds out! ;P Cheers The universe is driven by the complex interaction between three ingredients: matter, energy, and enlightened self-interest.
Thats why I said discretely :)
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
I was curious what developers thoughts are on what activities are most important during a development project handoff. Currently, the lead developer has accepted an employment offer with a different company and has given their two week notice. The coding this developer has been engaged in for the pass 6 months has been exclusively their own. There was little or no documentation effort which occurred during the design phase and the code, for the most part, is fairly undocumented. My question is: If you were assigned to assume this work, what specific activities would you do engage, if any, before the lead developer's last day? :omg:
Besides the mandatory kidnapping and brainwashing? Sodium Penathol rules, dude. If you're squeamish about disposing of the poor sod after you've fried out all his neurons, you can try the approach favored by Big Database Suppliers, and bribe the guy with booze and babes to stick around for a while. Or maybe that only works with elected officals. If that fails, tie his severance check to him documenting the code, and at least writing down the design ideas. If I was to assume his work, I would get him in a very small room with lots of coffee, and only you have the key to the door. Keep him there until you fully understand the base classes and general interfaces. Then he can go potty. Amazing with a full bladder can do to a man (women can hold it better I've found). But definatly spread it around he's a bum and not to be trusted with anything more than VB code...
Visual Studio Favorites - improve your development! GUIgui - skin your apps without XP
-
I was curious what developers thoughts are on what activities are most important during a development project handoff. Currently, the lead developer has accepted an employment offer with a different company and has given their two week notice. The coding this developer has been engaged in for the pass 6 months has been exclusively their own. There was little or no documentation effort which occurred during the design phase and the code, for the most part, is fairly undocumented. My question is: If you were assigned to assume this work, what specific activities would you do engage, if any, before the lead developer's last day? :omg:
Been there....done that...it is not fun.... There are two areas of concern: Management expectations and inheriting the code. For Management: Get them to agree to the fact that all schedules must slip while someone learns the existing code. If they can't be convinced of this, then nothing else matters much....Inform them that there is no guarantee about the quality and completeness of the code and that some unknown-yet-vast percentage of the code must be thoroughly combed through and possibly scrapped/redesigned/reworked etc. If mgmt does not agree, leave Dodge on the next available stage.... For the 'other developer': Here your challenge is to absorb multiple months of code in a few days....Not a likely proposition. So it may be best to focus on what is not done yet, or worse what is half done....Since mgmt is likely expecting little interruption of progress it is more efficient to try to ascertain the 'tip of progress' rather than study the wake of where the code has already been. 1. Find out what 'works' and what *doesn't* 2. Find out what is 'half done' 3. Determine the quality of any regression tests the developer uses so that you attempt to discover the quality and completeness of the code. 4. Ask them for their 'to do list' and what they were working on last as well as its state of correctness/completeness. 5. Use a tape recorder to record as many all day code walk throughs as *you* [not him] has time for....Put all other projects aside and drain the other guy's brain....During these interviews make sure you record important function names, source file names, line #'s etc....in short all the things you'll need to be able to navigate this pile of work.... 6. Get the developer to provide as many architectural design / class design / 'approaches to the problem' as you can....Often high level understanding can help reduce the tendancy to get overloaded by the volume of the work being being handed off.... Just trying to keep the forces of entropy at bay
-
I was curious what developers thoughts are on what activities are most important during a development project handoff. Currently, the lead developer has accepted an employment offer with a different company and has given their two week notice. The coding this developer has been engaged in for the pass 6 months has been exclusively their own. There was little or no documentation effort which occurred during the design phase and the code, for the most part, is fairly undocumented. My question is: If you were assigned to assume this work, what specific activities would you do engage, if any, before the lead developer's last day? :omg:
Force him to sit down and document / put comments in! :eek: Then pray...
I've always heard that there was an idea behind Win ME... I still can't figure out what that was... anyboy know??? I;ve herad the idea was that it was supposed to be n operating system but I doubt this. - Brian Delahunty
-
I was curious what developers thoughts are on what activities are most important during a development project handoff. Currently, the lead developer has accepted an employment offer with a different company and has given their two week notice. The coding this developer has been engaged in for the pass 6 months has been exclusively their own. There was little or no documentation effort which occurred during the design phase and the code, for the most part, is fairly undocumented. My question is: If you were assigned to assume this work, what specific activities would you do engage, if any, before the lead developer's last day? :omg:
Kidnapping springs to mind..... :laugh: Would you like to meet my teddy bear ?
-
The code documentation effort sits at the top of the to do list. It is my sense that the developer was planning on doing this at the end of the development cycle, however now that this developer is moving on, their is complete understanding of the importance of completing this task now. There is a total of 60 some classes in the project and our goal is to at least attempt to document 80 to 95 percent of these classes in the next week. The source code has been backed up, so we are covered there.
-
Richard Cunday wrote: If you were assigned to assume this work, what specific activities would you do engage, if any, before the lead developer's last day? Buy him/her a six pack....make that a case of beer and then nicely ask them about the intricacies of the application. Give the beer to them after they have explained what you need to know. :) Nick Parker
May your glass be ever full. May the roof over your head be always strong. And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
Unfortunately, I believe this developer does not drink. Besides that, If I did by a six pack, I probably would have ended up drinking the stuff in the parking lot considering my state of mind yesterday. Today, thing seem to be more settled.
-
I'd concur with the guy who said burn a copy NOW. Do you have sourcesafe or similar to check the changes he makes ? The lack of documentation means basically you're lucky to lose him. In the meantime, someone should sit with him and get everything explained and documented at the same time. Someone sitting with him is the only way to ensure the questions answered are the ones that need asking, no matter how good his intentions. Christian No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002 Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002 During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
Good suggestions. Here what the immediate plan is: 1) Determine what is not working and what functionality is outstanding. We spent roughly two hours discussing this. We have sat down together and I was given a one-on-one demo of the application to get a basic understanding of the general functionality of the application. During the demo, addition bugs were detected, and we added these items to the growing to-do list. 2) The next thing we did today (day 1) was print out the high level design document and we briefly discussed the functional grouping of the various classes. Tommorrow, the plan is for me to get a general understanding of the communication layer between the client and server components. This weekend, I am planning on attempting to work though the necessary code changes to implement a feature which has not yet been implemented. Hopefully, this exercise will help me gauge the extend of the work that is required to extend, support and maintain this application. My thinking is that this if I run into technical problems, with building, debugging, etc. that I will have a better idea of what questions to ask before the developer's last day..
-
Been there. And thanks to a fantastic turn of management, I only had two days, even though they had a month's notice. Getting him to document the code properly wasn't an option. Option 1: Get him to talk the new company into finding you a job as well. Option 2: Go find somewhere else to work yourself. Option 3: Quickly make yourself invaluable to any other project you can find. Failing all those (as I did through naivety), get a very good overview of the product then tell management that because of their incompetence you have to go through and comment the code yourself. Take a good hard backup and start doing just that, it's a hell of a learning experience. If the code is small enough that you can get him to document it ten by all means do so, but get the management to break the news to him, they may be more tactful :) Paul I think there're pieces of me you've never seen - Tori Amos, Tear in Your Hand
Good suggestion about commenting the code myself. It makes sense to do it yourself as a method to improving the general understanding of how the code works.
-
Been there....done that...it is not fun.... There are two areas of concern: Management expectations and inheriting the code. For Management: Get them to agree to the fact that all schedules must slip while someone learns the existing code. If they can't be convinced of this, then nothing else matters much....Inform them that there is no guarantee about the quality and completeness of the code and that some unknown-yet-vast percentage of the code must be thoroughly combed through and possibly scrapped/redesigned/reworked etc. If mgmt does not agree, leave Dodge on the next available stage.... For the 'other developer': Here your challenge is to absorb multiple months of code in a few days....Not a likely proposition. So it may be best to focus on what is not done yet, or worse what is half done....Since mgmt is likely expecting little interruption of progress it is more efficient to try to ascertain the 'tip of progress' rather than study the wake of where the code has already been. 1. Find out what 'works' and what *doesn't* 2. Find out what is 'half done' 3. Determine the quality of any regression tests the developer uses so that you attempt to discover the quality and completeness of the code. 4. Ask them for their 'to do list' and what they were working on last as well as its state of correctness/completeness. 5. Use a tape recorder to record as many all day code walk throughs as *you* [not him] has time for....Put all other projects aside and drain the other guy's brain....During these interviews make sure you record important function names, source file names, line #'s etc....in short all the things you'll need to be able to navigate this pile of work.... 6. Get the developer to provide as many architectural design / class design / 'approaches to the problem' as you can....Often high level understanding can help reduce the tendancy to get overloaded by the volume of the work being being handed off.... Just trying to keep the forces of entropy at bay
Excellent recommendations. Item 1 and 2 was the first thing we tackled and after I was given a demo of the application, additional items was added to the list which to the developer's surprise had been previously thought to be working. Item 3 is another great suggestion. This actually came up during the demo of the application where the developer immediately saw that something was broken, but this was not obviously to me. Capturing the unit and regression test cases is very important. I need to know how to quickly detect when the application is broken. Item 5 great idea. I would have never though of using a tape recorder to capture comments of the code walk-throughs. This makes perfect sense to me that I could easily miss an important point in note taking and recording the session would allow me to go back and review the recording to pick up this information. Thank you very much for these useful suggestions!! It is greatly appreciated.:-D