I have to confess, I cannot move, I am scared.
-
guys, recently I had to do some work on a different product. There are two developers who normally work on the product, but one is ill, one on vacation. Okay, new functionality has to be implemented, I've never saw that code. And I wished I never had. I found one control that has 15.000 (fifteen thousand?) lines of code. The whole code is a mess. I didn't get it compiling for hours due to different 3rd party libs that are used throughout the product. I never understood who anyone could do something like this. There are a lot of good reasons for a good, solid architecture, but the most important is to know that maintenance will not kill you. I guess these guys are tougher than me. You know you live, when it hurts. And these guys seem to really feel the life going through their veins. I just stare onto that code and ask myself where to begin. As I said. I cannot move. I am scared. (Anyone remembers this "one broken window" story from the pragmatic programmers? This was war here) nice weekend guys.
Young developers are never scared :) (Yep, i'm one), one of my first jobs was to maintain an application that was right in the middle of being a great idea and a total mess, parts of it were well thought, other were overenginered solutions and others were simply hacky (yes, it had passed by several hands), it took me a while to get through (bless the debuggers), so in some way i understand your fear to touch that code, but i assure you will find your way too.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Hiro_Protagonist_ wrote:
I found one control that has 15.000 (fifteen thousand?) lines of code.
I'm curious... What kind of control has that much code?
That's another story. It's a WPF control, the 15.000 lines are in the code behind. (Did I say that these facts are even hard to write down?) It represents a task pane in Excel where most of the functionality is configurable. I guess it's a perfect sample for beginners that they can check how good they can work with legacy code when there is no architectural thinking before coding at all. I still cannot believe it. :)
-
Young developers are never scared :) (Yep, i'm one), one of my first jobs was to maintain an application that was right in the middle of being a great idea and a total mess, parts of it were well thought, other were overenginered solutions and others were simply hacky (yes, it had passed by several hands), it took me a while to get through (bless the debuggers), so in some way i understand your fear to touch that code, but i assure you will find your way too.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
Oh, don't get me wrong. I don't have any issues to touch it. I was just blown away because I didn't expect anything like this. It simply took ist time to get to work again, after seeing that stuff. :) It is totally okay that things are not perfect, I also expect if there is mostly readable code and I don't mind if I see rubbish. I certainly made enough mistakes by myself. It was just the dimension of rubbish that made me moveless and scared. :)
-
guys, recently I had to do some work on a different product. There are two developers who normally work on the product, but one is ill, one on vacation. Okay, new functionality has to be implemented, I've never saw that code. And I wished I never had. I found one control that has 15.000 (fifteen thousand?) lines of code. The whole code is a mess. I didn't get it compiling for hours due to different 3rd party libs that are used throughout the product. I never understood who anyone could do something like this. There are a lot of good reasons for a good, solid architecture, but the most important is to know that maintenance will not kill you. I guess these guys are tougher than me. You know you live, when it hurts. And these guys seem to really feel the life going through their veins. I just stare onto that code and ask myself where to begin. As I said. I cannot move. I am scared. (Anyone remembers this "one broken window" story from the pragmatic programmers? This was war here) nice weekend guys.
Okay...I'm weird, I admit it. 1) 3rd party libs - I don't have a problem using them. I have a problem that the build script / Source Code Control doesn't include them. Having to go get them is bad. (You did fix this as you went forward, right?) 2) 15,000 lines for one control. Seems high, but I've seen worse....occassionally I have written worse. 3) Where do you start? Back to the build script. You do have Source Code Control (please tell me yes...if not, get Git and put it under Source Code Control - ANY Source Code Control) With Source Code Control and a consistent build process, you can begin to code fearlessly. (Your code may never be used, but you can start).
-
Oh, don't get me wrong. I don't have any issues to touch it. I was just blown away because I didn't expect anything like this. It simply took ist time to get to work again, after seeing that stuff. :) It is totally okay that things are not perfect, I also expect if there is mostly readable code and I don't mind if I see rubbish. I certainly made enough mistakes by myself. It was just the dimension of rubbish that made me moveless and scared. :)
I'm glad it was just the initial shock. ;)
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Write good code and sooner or later your boss will not need you anymore. Write such a mess and you have work forever and they can't afford to fire you. The good thing is that it does not matter where you begin. Any part is just as good as another.
CDP1802 wrote:
Write good code and sooner or later your boss will not need you anymore
I used to have exactly this problem. If I did my job perfectly, I was completely invisible; servers didn't crash, the database didn't slow down, calls were routed correctly, network outages were promptly reported. The only time anyone remembered I worked there was when things went wrong. I even worked on a different floor than the rest of the company. I worked on a business management system that literally ran the whole company. When it was down, 80 people were sitting at their desks twiddling their thumbs. I used to say that I earned my whole salary on two days a year, if I got the system back on-line in an hour instead of a day, that's how much money the company saved. No pressure.
-
guys, recently I had to do some work on a different product. There are two developers who normally work on the product, but one is ill, one on vacation. Okay, new functionality has to be implemented, I've never saw that code. And I wished I never had. I found one control that has 15.000 (fifteen thousand?) lines of code. The whole code is a mess. I didn't get it compiling for hours due to different 3rd party libs that are used throughout the product. I never understood who anyone could do something like this. There are a lot of good reasons for a good, solid architecture, but the most important is to know that maintenance will not kill you. I guess these guys are tougher than me. You know you live, when it hurts. And these guys seem to really feel the life going through their veins. I just stare onto that code and ask myself where to begin. As I said. I cannot move. I am scared. (Anyone remembers this "one broken window" story from the pragmatic programmers? This was war here) nice weekend guys.
I feel your pain; I recently joined such a team. Fear invites loathing over for dinner and an eventual desire to throw one's computer from the roof. Ironically my mess is in the name of easy maintenance. Copy & pasting thousands of lines of poorly written code from the mid-2000s is perfectly maintainable. After all, it’s all the same! JOY!!! :(( To quote somebody’s signature: Mind bleach, please send mind bleach...
-
wizardzz wrote:
is a mute point
I suspect making a point which is unhearable would be moot.
-
Okay...I'm weird, I admit it. 1) 3rd party libs - I don't have a problem using them. I have a problem that the build script / Source Code Control doesn't include them. Having to go get them is bad. (You did fix this as you went forward, right?) 2) 15,000 lines for one control. Seems high, but I've seen worse....occassionally I have written worse. 3) Where do you start? Back to the build script. You do have Source Code Control (please tell me yes...if not, get Git and put it under Source Code Control - ANY Source Code Control) With Source Code Control and a consistent build process, you can begin to code fearlessly. (Your code may never be used, but you can start).
-
guys, recently I had to do some work on a different product. There are two developers who normally work on the product, but one is ill, one on vacation. Okay, new functionality has to be implemented, I've never saw that code. And I wished I never had. I found one control that has 15.000 (fifteen thousand?) lines of code. The whole code is a mess. I didn't get it compiling for hours due to different 3rd party libs that are used throughout the product. I never understood who anyone could do something like this. There are a lot of good reasons for a good, solid architecture, but the most important is to know that maintenance will not kill you. I guess these guys are tougher than me. You know you live, when it hurts. And these guys seem to really feel the life going through their veins. I just stare onto that code and ask myself where to begin. As I said. I cannot move. I am scared. (Anyone remembers this "one broken window" story from the pragmatic programmers? This was war here) nice weekend guys.
Depending on just how old that application is, the code may actually be not that bad after all. It may just have grown that way over time. Also, judging by the large scale projects I worked on over the past couple of decades, it sometimes can take hours to successfully set up and build a project on a new system even if people are around to explain and help. No matter what you know about good architecture, and no matter how different the code looks to your ideal, it may once have been quite nice and sleek for the standards of the time it had been written in originally. Software lives. Software grows. Software rusts. As for "where to begin": 1. Try to pinpoint the modules and functions that are relevant for your task. If required, use the debugger and step through the code until you find them. 2. Use the debugger and any other tool you have to fully understand what these parts of the code do. Once you understood a chunk of code, add that as comment! But don't change the code just yet! (the other devs may later be able to verify by those comments you got it, or point out things that you missed) 3. Identify the pieces of code you need to modify. Try to change as little as possible: add the new code as functions that are called from the relevant points of the original code. Make sure to properly comment what exactly these functions do, what preconditions they have (i. e. what assumptions you made of the state of the program), and what postconditions they have (i. e. what the functions change within the overall state of the program) 4. In your new functions, place asserts to verify your assumptions about the preconditions hold. Depending on the complexity of the function, also place asserts to verify the post conditions. 5. Check error conditions and exceptions, and make sure you're treating these cases correctly. 6. Don't try to change/improve anything beyond the change you're supposed to do. chances are that even if there is potential for improvement, you don't understand the full scope of that piece of program and during refactoring accidentally omit treating a specific corner case, or three. 7. Once you can get your hands on one of the devs, make sure you've done it right and didn't forget some corner cases. Also make sure they understand the scope of your change: they will have to maintain it later. This should be easy if you followed advice 3 above.
-
Depending on just how old that application is, the code may actually be not that bad after all. It may just have grown that way over time. Also, judging by the large scale projects I worked on over the past couple of decades, it sometimes can take hours to successfully set up and build a project on a new system even if people are around to explain and help. No matter what you know about good architecture, and no matter how different the code looks to your ideal, it may once have been quite nice and sleek for the standards of the time it had been written in originally. Software lives. Software grows. Software rusts. As for "where to begin": 1. Try to pinpoint the modules and functions that are relevant for your task. If required, use the debugger and step through the code until you find them. 2. Use the debugger and any other tool you have to fully understand what these parts of the code do. Once you understood a chunk of code, add that as comment! But don't change the code just yet! (the other devs may later be able to verify by those comments you got it, or point out things that you missed) 3. Identify the pieces of code you need to modify. Try to change as little as possible: add the new code as functions that are called from the relevant points of the original code. Make sure to properly comment what exactly these functions do, what preconditions they have (i. e. what assumptions you made of the state of the program), and what postconditions they have (i. e. what the functions change within the overall state of the program) 4. In your new functions, place asserts to verify your assumptions about the preconditions hold. Depending on the complexity of the function, also place asserts to verify the post conditions. 5. Check error conditions and exceptions, and make sure you're treating these cases correctly. 6. Don't try to change/improve anything beyond the change you're supposed to do. chances are that even if there is potential for improvement, you don't understand the full scope of that piece of program and during refactoring accidentally omit treating a specific corner case, or three. 7. Once you can get your hands on one of the devs, make sure you've done it right and didn't forget some corner cases. Also make sure they understand the scope of your change: they will have to maintain it later. This should be easy if you followed advice 3 above.
Thanks for that descriptive explanation. The code isn't too old, it's just some years. I already answered before, I do know what do to and how, it was just the initial shock that made me unable to move. It is not my task to refactor all that stuff and bring it to a nowadays acceptable architecture (thank god). You are certainly right, this code could be acceptable to some degree considering the time when it was made. In this case, it is just bad messy code without any architectural thoughts. I don't see anything that would make it acceptable due to coding guidelines, best practices or whatever. That doesn't help, certainly :). And it doesn't make a difference. Nevertheless, thanks for your answer. :)
-
Thanks for that descriptive explanation. The code isn't too old, it's just some years. I already answered before, I do know what do to and how, it was just the initial shock that made me unable to move. It is not my task to refactor all that stuff and bring it to a nowadays acceptable architecture (thank god). You are certainly right, this code could be acceptable to some degree considering the time when it was made. In this case, it is just bad messy code without any architectural thoughts. I don't see anything that would make it acceptable due to coding guidelines, best practices or whatever. That doesn't help, certainly :). And it doesn't make a difference. Nevertheless, thanks for your answer. :)
I suppose whether it's actually bad or only apparently so doesn't really make a difference to you. Put your blinders on and carefully attach whatever is needed. I hope you got your bargepole handy in case you need to touch that code ;)