Managing Another Developer's Project
At work, I've been promoted to a software engineer position. Which I'm really excited for. Originally, I was hired to support hardware technicians. But in the past year, I've been making software for the company. I wanted to show them what I could do and it seems to have paid off.
The problem, is that I'm getting ready to take over a project another guy created some time ago. He's the only one to ever work on this project and he's never had to report to anyone. So he's been able to do whatever he wanted, without recourse.
In the end though, the software works. It is just super frustrating because now I have to manage the code... and I'm frightened. I can tell he's an old VB6 developer, because he uses a lot of the old classes and APIs, instead of the newer .NET classes. Which isn't really a problem, but it's completely inefficient.
There's one section of code that he uses to grab the icons in a folder. I can't remember how long the code file was, but it had to have been 30-40 lines for just this. When you can do that in around 5 lines using .NET classes instead of the API. There's a ton of things like this. There's also almost no commenting, he ignores all errors, uses GoTo like it was mankind's savior and much, much more.
Monday is when I'll get a chance to really work on it, but I know I have a lot of work ahead of me. One of the senior developers had a chance to look at the code and he cringed. My manager told me to focus on cleaning up the code in the next 2 weeks. Doing so won't be terribly difficult, but it's going to be time consuming.
So this is me ranting, but does anyone else have any other stories like this? I'm curious.
Re: Managing Another Developer's Project
If it's a significant project, you're not going to just "clean up" the code in 2 weeks. 2 weeks may not be enough time to even understand the code, let alone clean it up.
Move slowly here. I don't think you mentioned whether or not the original author is still around or not but if he is I'd pick his brains as much as possible. If not then spend as much time as possible figuring out what he was doing. The only "clean up" you should consider doing at first might be to insert commentary into the code as you learn the intent, but don't touch the actual code right away.
In the system I have now owned for nearly 13 years it took me eight months before I could proficiently fix bugs in it. The code was a large business-rules calculations engine that had hundreds of customers using it so, obviously I couldn't just dive in and "clean it up" right away.
-Max :D
Re: Managing Another Developer's Project
Quote:
Originally Posted by
Max Peck
If it's a significant project, you're not going to just "clean up" the code in 2 weeks. 2 weeks may not be enough time to even understand the code, let alone clean it up.
Move slowly here. I don't think you mentioned whether or not the original author is still around or not but if he is I'd pick his brains as much as possible. If not then spend as much time as possible figuring out what he was doing. The only "clean up" you should consider doing at first might be to insert commentary into the code as you learn the intent, but don't touch the actual code right away.
In the system I have now owned for nearly 13 years it took me eight months before I could proficiently fix bugs in it. The code was a large business-rules calculations engine that had hundreds of customers using it so, obviously I couldn't just dive in and "clean it up" right away.
-Max :D
This project is just used internally. I think it's around 10,000 lines of code, but I can't be sure. It also seems fairly predictable. I've done a lot of the same work that this application does, in the past, so I'm confident that it shouldn't take too long to clean it up.
I've spent the last few days understanding what the software does and how all the parts work together. I think I have a fairly good understanding of how everything works together.
As for the developer, he's been going over the project with me, but you can tell he's checked out. So it's been difficult to get anything out of him. He's leaving the company and his last day is Friday.
As for your suggestion, I think that's a great idea. I had already planned on created comments, but I wanted to do so as I was editing things. However, making comments forces me to understand every method and property alike. So that should be a good start. Then I can go back as I have time.
Re: Managing Another Developer's Project
Quote:
So this is me ranting, but does anyone else have any other stories like this?
Oh my yes... There are so many horribly kludged-together systems I have to work with... And they get so ingrained - people just keep working with them, propping them up instead of tearing out and fixing it. I try to make improvements where I can, but as Max mentions, you usually have to take it slow so you don't botch it all up.
It's very frustrating... but then I also think how there was some pretty stupid code I wrote on old jobs too (out of inexperience, not intention).
Re: Managing Another Developer's Project
Quote:
My manager told me to focus on cleaning up the code in the next 2 weeks. Doing so won't be terribly difficult, but it's going to be time consuming.
Being an Internal system it matters less, but be careful. There could be unintended consequences to changing it.
We had a incident were we cleaned up and area of code in one of our systems and when our customers updated to the new version as they typed stuff into text boxes in various places in our application it would apparently attempt to randomly paste whatever was on the clip board into the text box.
Basically it was a problem with the ctl + V key mapping but it was a nightmare for about a week, and we introduced this error ourselves by 'cleaning up' some code.
All i am saying is it is easy to break bad code by attempting to fix it.
Re: Managing Another Developer's Project
Is it possible to copy the project into a test environment working on test data so that you can break it all you want without causing the company any problems?
Re: Managing Another Developer's Project
The number if lines used is not a sensible measure of code quality.
Re: Managing Another Developer's Project
It is, however, a pretty good measure of code annoyance when it comes to maintenance. I was working on a project that had a very large amount of uncalled methods. Nothing is more chaff than whole series of uncalled methods in code. Whenever I wanted to understand what function F did, I had to look at all the places that F was being called, then walk back up those stacks to see whether or not F really was being called by any of them, or if only one of the chains was actually reachable by code. Eventually, I stripped thousands of lines of unreachable code out of that project, but not right off, nor am I certain that I have gotten it all. A function like this:
Code:
Public Function DoSomeWork As Boolean
Return True
End Function
Is three lines of code, and a legitimate function, but useful???? Not so much! There's probably a fair amount of that left in the project that I have yet to find.
I should also mention that there was a reason why there was so much chaff in this code, which I won't go into. Chaff it was, and chaff it will remain, but that's chaff through the thresher, by now.
Re: Managing Another Developer's Project
Quote:
Originally Posted by
weirddemon
This project is just used internally. I think it's around 10,000 lines of code, but I can't be sure. It also seems fairly predictable. I've done a lot of the same work that this application does, in the past, so I'm confident that it shouldn't take too long to clean it up.
Cool.
Quote:
As for the developer, he's been going over the project with me, but you can tell he's checked out. So it's been difficult to get anything out of him. He's leaving the company and his last day is Friday.
Heh ... at least you've had some time. The owner of my Rules Engine spent a grand-total of one hour :eek: with me before he left the company for greener pastures!
Quote:
As for your suggestion, I think that's a great idea. I had already planned on created comments, but I wanted to do so as I was editing things. However, making comments forces me to understand every method and property alike. So that should be a good start. Then I can go back as I have time.
It never hurts to insert (liberally) comment sections that explain what a section of code is up to.
-Max :D
Re: Managing Another Developer's Project
Quote:
Originally Posted by
wossname
The number if lines used is not a sensible measure of code quality.
What you said +1
Re: Managing Another Developer's Project
Hmmm.....
10.000 lines of code in 2 weeks to "clean up"?
If you change something on the left it will go wrong some where on the right.
Re: Managing Another Developer's Project
Quote:
Originally Posted by
Shaggy Hiker
Is it possible to copy the project into a test environment working on test data so that you can break it all you want without causing the company any problems?
Yes... and no. The application relies heavily on a database. So anything I change, will affect records all in real time. The last guy did all of his testing on the live databases. However, I'm going to duplicate the databases so that I can test whatever I want, without causing problems for the company.
Quote:
Originally Posted by
wossname
The number if lines used is not a sensible measure of code quality.
I'm not sure what you're getting at here. I never implied that. I only said that it was 10,000 lines of code to better represent the amount of work I have to do. I never mentioned quality in relation to quantity. Can you clarify?
Quote:
Originally Posted by
namrekka
Hmmm.....
10.000 lines of code in 2 weeks to "clean up"?
If you change something on the left it will go wrong some where on the right.
I don't think everything will need to be changed. But I guess a vast majority will have to be changed in some way or another. But yeah, it's going to take longer than 2 weeks. I don't think my manager is overly concerned, she just wants it done when I can get to it.
I talked to her more about it on Friday. I told her the "cleanup" would be sort of a secondary task. We just had our QBR, and the client gave us a bunch of changes and additions that need to be completed.
So what I think I'll do is clean up the code in sections of the project I'm adding to or changing, first. Then when I have time, I'll go back and fix the miscellaneous things.
First things first though, I'll need to create a test server and backup the project regularly. The project was just on this guy's PC. Not anywhere on the network, any backup servers... nothing. I was fairly surprised.
Re: Managing Another Developer's Project
Guess what, we have been working on an app for the better part of a year, and it's still not a functioning app. I have been rewriting it in the past three days and I think I could finish the task single handed in about a week's time. Wonder where all the time goes...
.
Re: Managing Another Developer's Project
Quote:
Originally Posted by
wossname
The number if lines used is not a sensible measure of code quality.
I don't entirely agree. Given two code snippets that always accomplish the same thing in a similar amount of clock cycles, the one with fewer lines of code is usually better. (Not always.)
edit: assuming sane code formatting, of course...
Re: Managing Another Developer's Project
Trouble is finding two code snippets which do exactly the same thing. Modern principles of code reuse dictate that such snippets cannot exist.
.
Re: Managing Another Developer's Project
Been doing it my whole carer:rolleyes:
My advice: Don't try to "clean it up". After all, what would be the point? If something's working, leave it the hell alone. Your goal shouldn't be an elegant system, it should be a working system. And playing around with the code just to make it look nice is really just padding your own ego at the risk of stability.
What you should be concentrating on is fixing bugs and implementing new features. Every time you do that, make sure you write your code elegantly. That might mean cleaning up a few bits and bobs around the part you're working on but only if they really NEED it. Don't tidy them just because they offend you.
If you always try to write decent code yourself and leave the extant code alone then, slowly but surely, the parts of the system that change most and need ongoing maintenance end up being well written. And if the the other stuff is still badly written, why do you care? You won't be maintaining it because, if it needed maintaining you'll already have cleaned it.
edit> Of course, bitching and moaning about the previous deveopler to everyone that'll listen is a perfectly acceptable practice. In fact it's practically obligatory.
Re: Managing Another Developer's Project
Quote:
Of course, bitching and moaning about the previous deveopler to everyone that'll listen is a perfectly acceptable practice. In fact it's practically obligatory.
Rule of thumb in our company, actually.
Re: Managing Another Developer's Project
Quote:
Originally Posted by
FunkyDexter
Been doing it my whole carer:rolleyes:
My advice: Don't try to "clean it up". After all, what would be the point? If something's working, leave it the hell alone. Your goal shouldn't be an elegant system, it should be a working system. And playing around with the code just to make it look nice is really just padding your own ego at the risk of stability.
What you should be concentrating on is fixing bugs and implementing new features. Every time you do that, make sure you write your code elegantly. That might mean cleaning up a few bits and bobs around the part you're working on but only if they really NEED it. Don't tidy them just because they offend you.
If you always try to write decent code yourself and leave the extant code alone then, slowly but surely, the parts of the system that change most and need ongoing maintenance end up being well written. And if the the other stuff is still badly written, why do you care? You won't be maintaining it because, if it needed maintaining you'll already have cleaned it.
edit> Of course, bitching and moaning about the previous deveopler to everyone that'll listen is a perfectly acceptable practice. In fact it's practically obligatory.
This is one of those "Yes" and "No" kind of situations, I think.
The software works, that much is clear. But the way he programmed it not only looks awful, from a code point of view but is very hard to manage.
I'll give you an example.
Today, I had to figure out why the serial number the app was pulling from the hard drive, was different than the one that the receiver had entered into the database earlier that day.
To do this, I looked through each step of the code. Before the test begins, the application goes through a "data verification" process. It was just a method located on the main form. No problems there.
Within this method, I located the section where he was checking for the serial number. This is where it became a pain. In this method, he calls another method that calls another method in a class file, which gets it's data from another class file. It was a pain to track all of this down.
Instead, it would have been much simpler to make the first two methods one method and put the last two into one class file. The last two methods only retrieved the HDD and the SN. Both of which could have been done in either one method in one class file or two methods in one class file. I think the second method is used separately elsewhere, so that would make sense.
So situations like this make it super hard to figure out issues. That's not evening mentioning all the other methods used in between.
Re: Managing Another Developer's Project
Quote:
from a code point of view but is very hard to manage
Then don't. That's the point.
Quote:
it would have been much simpler to make the first two methods one method and put the last two into one class file.
Assuming it was pulling the wrong serial number (which you don't explicitely state but I think that's what you're saying) then what you describe is exactly what you should do. But ONLY if it's pulling the wrong serial number. If it's pulling the right one then you don't really care how.
The point is that you fix the bits that need fixing and only bits that need fixing. And when you fix something you fix it right. What you don't do is examine a piece of code, realise it's producing the right result but it was complicated to follow and decide to rewrite it on that basis. At best that's non-productive effort and at worst it'll introduce bugs because there'll be some aspect of it you missed (highly likely if it's that badly written and difficult to follow).
When people talk about "Cleaning Up" code they usually mean they're going to rewrite elements just to make them look tidier and more elegant. That's a mug's game and you will probably never complete it. Even if you do you won't have achieved anything of real use to your user. A badly written app is difficult to maintain. So only maintain the bits that need maintaining. You'll know which bits they are because they'll be the bits you need to change to fix a bug or implement a feature.
Re: Managing Another Developer's Project
Quote:
Originally Posted by
FunkyDexter
The point is that you fix the bits that need fixing and only bits that need fixing. And when you fix something you fix it right. What you don't do is examine a piece of code, realise it's producing the right result but it was complicated to follow and decide to rewrite it on that basis. At best that's non-productive effort and at worst it'll introduce bugs because there'll be some aspect of it you missed (highly likely if it's that badly written and difficult to follow).
When people talk about "Cleaning Up" code they usually mean they're going to rewrite elements just to make them look tidier and more elegant. That's a mug's game and you will probably never complete it. Even if you do you won't have achieved anything of real use to your user. A badly written app is difficult to maintain. So only maintain the bits that need maintaining. You'll know which bits they are because they'll be the bits you need to change to fix a bug or implement a feature.
I fully agree.
