Developer just left - I'm stuck with all his projects
-
Hi guys, I'm in coding hell. One of our developers just left, I ('m a developer myself) find myself being handed his projects. One of them is a patient tracking web application which he - since no-one was looking over his shoulder and he really cared for javascript - decided to develop as basically a javascript application which speaks to the server via xmlhttp. No problem with his choice, only I'm facing frustrations from the users, who are finding bugs and I have to debug this application. But it's damn near undocumented, so that's near 5000 lines of undocumented javascript, full of abbreviations and it damn near looks like it's been through an obfuscator. On top of that, he opted to develop it as a sort of generic application he could reuse for other projects. Again, no problem with this choice, only he's not really around anymore to develop this plan further, and meanwhile the app is certainly not as simple as it would've been if he'd gone straight for a one project-one solution deal. It's a mash-up of xxx init-files, xxx xslt transformation files, oh my God. I guess my questions is this, what is a reasonable amount of time I could claim before my superious I need in order to fully come to terms with this project, and understand the application enough to debug it to the client's satisfaction? Solve their problems, i.e. Said superious seem to stick by the idea I should be able to do this in (the project in question took the departed developer 3/4 year to code) before Christmas, certainly taking no longer than the end of the year. Right now, sitting here and staring at near obfuscated javascript code, I'm thinking "if I had half the time the guy spent on coding it, maybe I'll get there.". But perhaps the ratio of understanding undocumented spaghetti-code vs. developing said code be more like 1:1? What's your guys idea on this ratio? Note there's a bit of documentation on the business logic and validation rules, so it's not a completely blank page - only almost. Thanks in advance, Morten
It is a bad situation. Understanding messy code can take several times longer than it took to write it in the first place. If the code doesn't have good unit test coverage it's even harder because you don't know if the changes you make have broken anything else. You need to explain this to your supervisors, otherwise they will have the same expectations of you as they had of him. Non-programmer managers don't tend to understand this kind of concept, they think you can just pick up and work with any code. Maybe try explaining it to them in examples they might understand. It's like looking for lost keys in someone else's house. In your own house you know the likely places to look. In someone else's house, you don't have a clue where to start. You also can't predict how long it will take. You might find the keys in 5 minutes if you get lucky. It may take you days if you don't.
Simon
-
It is a bad situation. Understanding messy code can take several times longer than it took to write it in the first place. If the code doesn't have good unit test coverage it's even harder because you don't know if the changes you make have broken anything else. You need to explain this to your supervisors, otherwise they will have the same expectations of you as they had of him. Non-programmer managers don't tend to understand this kind of concept, they think you can just pick up and work with any code. Maybe try explaining it to them in examples they might understand. It's like looking for lost keys in someone else's house. In your own house you know the likely places to look. In someone else's house, you don't have a clue where to start. You also can't predict how long it will take. You might find the keys in 5 minutes if you get lucky. It may take you days if you don't.
Simon
-
I wish I could take credit for that analogy, but someone else posted it here a few days ago. (I can't remember who though, so whoever it was, if your reading this, make yourself known and have some credit ;) )
Simon
-
It is a bad situation. Understanding messy code can take several times longer than it took to write it in the first place. If the code doesn't have good unit test coverage it's even harder because you don't know if the changes you make have broken anything else. You need to explain this to your supervisors, otherwise they will have the same expectations of you as they had of him. Non-programmer managers don't tend to understand this kind of concept, they think you can just pick up and work with any code. Maybe try explaining it to them in examples they might understand. It's like looking for lost keys in someone else's house. In your own house you know the likely places to look. In someone else's house, you don't have a clue where to start. You also can't predict how long it will take. You might find the keys in 5 minutes if you get lucky. It may take you days if you don't.
Simon
Simon Stevens wrote:
need to explain this to your supervisors, otherwise they will have the same expectations of you as they had of him. Non-programmer managers don't tend to understand this kind of concept, they think you can just pick up and work with any code
Good luck to him.
Simon Stevens wrote:
like looking for lost keys in someone else's house. In your own house you know the likely places to look. In someone else's house, you don't have a clue where to start. You also can't predict how long it will take. You might find the keys in 5 minutes if you get lucky. It may take you days if you don't.
Excellent way of putting it. Got my five :)
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
Hi guys, I'm in coding hell. One of our developers just left, I ('m a developer myself) find myself being handed his projects. One of them is a patient tracking web application which he - since no-one was looking over his shoulder and he really cared for javascript - decided to develop as basically a javascript application which speaks to the server via xmlhttp. No problem with his choice, only I'm facing frustrations from the users, who are finding bugs and I have to debug this application. But it's damn near undocumented, so that's near 5000 lines of undocumented javascript, full of abbreviations and it damn near looks like it's been through an obfuscator. On top of that, he opted to develop it as a sort of generic application he could reuse for other projects. Again, no problem with this choice, only he's not really around anymore to develop this plan further, and meanwhile the app is certainly not as simple as it would've been if he'd gone straight for a one project-one solution deal. It's a mash-up of xxx init-files, xxx xslt transformation files, oh my God. I guess my questions is this, what is a reasonable amount of time I could claim before my superious I need in order to fully come to terms with this project, and understand the application enough to debug it to the client's satisfaction? Solve their problems, i.e. Said superious seem to stick by the idea I should be able to do this in (the project in question took the departed developer 3/4 year to code) before Christmas, certainly taking no longer than the end of the year. Right now, sitting here and staring at near obfuscated javascript code, I'm thinking "if I had half the time the guy spent on coding it, maybe I'll get there.". But perhaps the ratio of understanding undocumented spaghetti-code vs. developing said code be more like 1:1? What's your guys idea on this ratio? Note there's a bit of documentation on the business logic and validation rules, so it's not a completely blank page - only almost. Thanks in advance, Morten
harleydk wrote:
I'm in coding hell
Yep. Been there. You have my sympathies. :)
Kevin
-
I wish I could take credit for that analogy, but someone else posted it here a few days ago. (I can't remember who though, so whoever it was, if your reading this, make yourself known and have some credit ;) )
Simon
I liked the analogy too. :)
Kevin
-
Hi guys, I'm in coding hell. One of our developers just left, I ('m a developer myself) find myself being handed his projects. One of them is a patient tracking web application which he - since no-one was looking over his shoulder and he really cared for javascript - decided to develop as basically a javascript application which speaks to the server via xmlhttp. No problem with his choice, only I'm facing frustrations from the users, who are finding bugs and I have to debug this application. But it's damn near undocumented, so that's near 5000 lines of undocumented javascript, full of abbreviations and it damn near looks like it's been through an obfuscator. On top of that, he opted to develop it as a sort of generic application he could reuse for other projects. Again, no problem with this choice, only he's not really around anymore to develop this plan further, and meanwhile the app is certainly not as simple as it would've been if he'd gone straight for a one project-one solution deal. It's a mash-up of xxx init-files, xxx xslt transformation files, oh my God. I guess my questions is this, what is a reasonable amount of time I could claim before my superious I need in order to fully come to terms with this project, and understand the application enough to debug it to the client's satisfaction? Solve their problems, i.e. Said superious seem to stick by the idea I should be able to do this in (the project in question took the departed developer 3/4 year to code) before Christmas, certainly taking no longer than the end of the year. Right now, sitting here and staring at near obfuscated javascript code, I'm thinking "if I had half the time the guy spent on coding it, maybe I'll get there.". But perhaps the ratio of understanding undocumented spaghetti-code vs. developing said code be more like 1:1? What's your guys idea on this ratio? Note there's a bit of documentation on the business logic and validation rules, so it's not a completely blank page - only almost. Thanks in advance, Morten
When i Started Development i had a Senior Developer Boss, atleast he was Still developing. He suddenly resigned for a post in another Firm, and i had to take over his Projects. The Man had this Attitude"Real Programmers Dont Comment their code, if its hard to write, it should be hard to understand" and when he Left i thought my life was over, i was a Junior and i was learning from him , and the Superiors expected more from me and instantly wanted deadlines and the sad part, they were no Developers and they had no clue what we are doing , You will hear them in the meeting talking about "Setup CD For a Web Application" :), "Double Clicking the exe and Click Next. i said to myself "Wow where did these gusy get what they are saying :) So i let them know that i have to understand what he was doing and what were you expecting from him, because apparantly the documentation was no where to be found and the code was not Commented at all. harleydk i think as the guys adviced, you have to make sure that you tell your Boss that it might take time to Debug, because you have to understand what he was doing. Good luck , i have already prayed for you
Vuyiswa Maseko, Sorrow is Better than Laughter, it may Sadden your Face, but It sharpens your Understanding VB.NET/SQL7/2000/2005 http://vuyiswamb.007ihost.com http://Ecadre.007ihost.com vuyiswam@tshwane.gov.za
-
When i Started Development i had a Senior Developer Boss, atleast he was Still developing. He suddenly resigned for a post in another Firm, and i had to take over his Projects. The Man had this Attitude"Real Programmers Dont Comment their code, if its hard to write, it should be hard to understand" and when he Left i thought my life was over, i was a Junior and i was learning from him , and the Superiors expected more from me and instantly wanted deadlines and the sad part, they were no Developers and they had no clue what we are doing , You will hear them in the meeting talking about "Setup CD For a Web Application" :), "Double Clicking the exe and Click Next. i said to myself "Wow where did these gusy get what they are saying :) So i let them know that i have to understand what he was doing and what were you expecting from him, because apparantly the documentation was no where to be found and the code was not Commented at all. harleydk i think as the guys adviced, you have to make sure that you tell your Boss that it might take time to Debug, because you have to understand what he was doing. Good luck , i have already prayed for you
Vuyiswa Maseko, Sorrow is Better than Laughter, it may Sadden your Face, but It sharpens your Understanding VB.NET/SQL7/2000/2005 http://vuyiswamb.007ihost.com http://Ecadre.007ihost.com vuyiswam@tshwane.gov.za
-
Hi guys, I'm in coding hell. One of our developers just left, I ('m a developer myself) find myself being handed his projects. One of them is a patient tracking web application which he - since no-one was looking over his shoulder and he really cared for javascript - decided to develop as basically a javascript application which speaks to the server via xmlhttp. No problem with his choice, only I'm facing frustrations from the users, who are finding bugs and I have to debug this application. But it's damn near undocumented, so that's near 5000 lines of undocumented javascript, full of abbreviations and it damn near looks like it's been through an obfuscator. On top of that, he opted to develop it as a sort of generic application he could reuse for other projects. Again, no problem with this choice, only he's not really around anymore to develop this plan further, and meanwhile the app is certainly not as simple as it would've been if he'd gone straight for a one project-one solution deal. It's a mash-up of xxx init-files, xxx xslt transformation files, oh my God. I guess my questions is this, what is a reasonable amount of time I could claim before my superious I need in order to fully come to terms with this project, and understand the application enough to debug it to the client's satisfaction? Solve their problems, i.e. Said superious seem to stick by the idea I should be able to do this in (the project in question took the departed developer 3/4 year to code) before Christmas, certainly taking no longer than the end of the year. Right now, sitting here and staring at near obfuscated javascript code, I'm thinking "if I had half the time the guy spent on coding it, maybe I'll get there.". But perhaps the ratio of understanding undocumented spaghetti-code vs. developing said code be more like 1:1? What's your guys idea on this ratio? Note there's a bit of documentation on the business logic and validation rules, so it's not a completely blank page - only almost. Thanks in advance, Morten
-
In truth? You are looking at a re-write. I just cannot phrase it any other way.
Charlie Gilley Will program for food... Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
I submit to you that you've arrived at the same conclusion as have I. I shall certainly be trying to sell it, it's the only feasible way to go. To code it back up, and documenting the new project so those who might take it up beyond me would stand a better chance than do I. I guess I can see it from my superiors view, they don't want to look at a another development bill when they already paid this departed developer 3/4 year to build a system. And it's gone live, and the clients are already paying for maintenance and support. I hate to post such a depressing news to them - because I'm afraid it'll reflect negatively on me; "that other guy could do it, why can't you." Non-programming superious, again... :((