Do you enjoy maintenance projects?
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
In a way. I like working with different stuff, so the challenge of maint sometimes makes up for the nightmaters. I also enjoy 'least impact' code, i.e. not leaving anything behind except the spec'd change, regardless of my desire to rewrite the whole damn thing.
-
That's mature...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Is this irony ? I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one. So I do not have anything against maintaining code, but having to do overtime just because the code is an uncommented mess and you nedd two hours instead of one to understand what is actually going on, not saying what it requires to change something without side-effects, is something I simply do not agree with. So I moved to something else, I think this is legal.
-
Phannon wrote:
very poor html
What HTML is good?
-
Is this irony ? I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one. So I do not have anything against maintaining code, but having to do overtime just because the code is an uncommented mess and you nedd two hours instead of one to understand what is actually going on, not saying what it requires to change something without side-effects, is something I simply do not agree with. So I moved to something else, I think this is legal.
Rage wrote:
I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one.
I don't know how you can make a statement like that. For example, there are BILLIONS of lines of Cobol that exist today, and MILLIONS more new lines of Cobol being written every year. Like Cobol, there are billions of lines of C++ code to maintain, but that certainly doesn't mean that nobody's writing new code. Yes, many programs are completely free of comments and/or documentation. Yes, that makes them a true bitch to work on. Yes, all of us have to do it, and you'll find that unless you're the first programmer to write code at a job, you're going to encounter legacy code that looks like crap (in your eyes). Maintenance coding is part of the job. If you don't like the idea of maintenance work, find another profession, because you can't quit every job that requires it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Rage wrote:
I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one.
I don't know how you can make a statement like that. For example, there are BILLIONS of lines of Cobol that exist today, and MILLIONS more new lines of Cobol being written every year. Like Cobol, there are billions of lines of C++ code to maintain, but that certainly doesn't mean that nobody's writing new code. Yes, many programs are completely free of comments and/or documentation. Yes, that makes them a true bitch to work on. Yes, all of us have to do it, and you'll find that unless you're the first programmer to write code at a job, you're going to encounter legacy code that looks like crap (in your eyes). Maintenance coding is part of the job. If you don't like the idea of maintenance work, find another profession, because you can't quit every job that requires it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
MILLIONS more new lines of Cobol being written every year.
Maybe, but I think that these lines of codes are written to maintain the BILLIONS of existing. I am not sure that there are that many new projects starting from scratch in COBOL.
John Simmons / outlaw programmer wrote:
because you can't quit every job that requires it.
No, but I can quit every job where the environment makes it even harder. As I said in my previous post, sure it is part of the job, sure I have and will surely again come across legacy code, but I will not accept to maintain it under all circumstances.
-
Nobody does usually. And there is a reason for that. If an old project needs to be maintained that usually means it's full of subtle bug that even the original creator haven't been able to fix. On top of that there is often and also a huge amount of patches plugged on top which don't work well with the main code. It's a nightmare. The only way to do a pleasant maintenance is appropriation. You need to do it full time for a while, and just rewrite things as you see fit. Of course there is always the additional hassle of the management who don't want any rewrite but just a quick and little (ahum, cough) fix... You need to explain them that doesn't work like that, and you can make it fun in the long run! ;)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
usually means it's full of subtle bug that even the original creator haven't been able to fix
No, it usually it just means that the original requirements have changed.
-
Super Lloyd wrote:
usually means it's full of subtle bug that even the original creator haven't been able to fix
No, it usually it just means that the original requirements have changed.
Well, I guess 'usually' was an inappropriate word. But because 'maintenance' could means both. And, for one, I have seen more of the bug thing that the requirement thing.
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Is this irony ? I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one. So I do not have anything against maintaining code, but having to do overtime just because the code is an uncommented mess and you nedd two hours instead of one to understand what is actually going on, not saying what it requires to change something without side-effects, is something I simply do not agree with. So I moved to something else, I think this is legal.
Rage wrote:
not saying what it requires to change something without side-effects, is something I simply do not agree with
This is where we would all benefit if mainstream languages supported design by contract. Of course devs would still have to write the contracts but if the language made it easy to do so it would encourage developers to do so.
Kevin
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Probably most of us don't. But it is a fact of life. Code has to be maintained so we must be prepared to perform these tasks. Occasionally it can be quite enjoyable and we can learn something from it - both when the code is bad and when the code is good. I didn't have to do much maintenance in my last contract. But just before the contract started I bought Working Effectively with Legacy Code[^]. I've read a fair bit of it and it's something I intend to make use of going forward. At least it's a way of adding some interest when faced with a horrendous maintenance project. Don't be fooled by the book's title though. "Legacy" means virtually all code that has to be maintained - even if it's spanking new .NET 3.5.
Kevin
-
Rage wrote:
not saying what it requires to change something without side-effects, is something I simply do not agree with
This is where we would all benefit if mainstream languages supported design by contract. Of course devs would still have to write the contracts but if the language made it easy to do so it would encourage developers to do so.
Kevin
Well-design and written code doesn't have "side-effects".
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Well-design and written code doesn't have "side-effects".
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Well I was interpreting side-effects in terms of mutability of state vs. non-mutability, e.g., as described in functional programming. http://en.wikipedia.org/wiki/Functional_programming[^] Contracts make it explicit (in code, as opposed to comments) what state is changed by a method.
Kevin
-
John Simmons / outlaw programmer wrote:
MILLIONS more new lines of Cobol being written every year.
Maybe, but I think that these lines of codes are written to maintain the BILLIONS of existing. I am not sure that there are that many new projects starting from scratch in COBOL.
John Simmons / outlaw programmer wrote:
because you can't quit every job that requires it.
No, but I can quit every job where the environment makes it even harder. As I said in my previous post, sure it is part of the job, sure I have and will surely again come across legacy code, but I will not accept to maintain it under all circumstances.
Rage wrote:
As I said in my previous post, sure it is part of the job, sure I have and will surely again come across legacy code, but I will not accept to maintain it under all circumstances.
And I simply agree with you.
-
Is this irony ? I think that in the C/C++ world, it is more likely nowadays to maintain code than create new one. So I do not have anything against maintaining code, but having to do overtime just because the code is an uncommented mess and you nedd two hours instead of one to understand what is actually going on, not saying what it requires to change something without side-effects, is something I simply do not agree with. So I moved to something else, I think this is legal.
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Depends on what "maintenance" means. If the project is still "life and active", fine. if the project is "dead because we don#t get any money for it anymore, but we have to fix bugs, so fix the bugs but with the least effort possible, no investments at all", it sucks for all involved. Fundamental problem: Most education is aimed at writing new code, though most programmers (what were the statistics? >70% or something?) work in maintenance.
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Only when I wrote the code in the first place.
John
-
Well I was interpreting side-effects in terms of mutability of state vs. non-mutability, e.g., as described in functional programming. http://en.wikipedia.org/wiki/Functional_programming[^] Contracts make it explicit (in code, as opposed to comments) what state is changed by a method.
Kevin
If the program has no observable side effects (using this strict definition), why should I run it at all? :D
-
If the program has no observable side effects (using this strict definition), why should I run it at all? :D
Well, that's what puzzles me about functional programming!:confused: But I've not looked into FP yet.
Kevin
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Only if I am given the freedom to improve, refactor, enhance, optimize, etc. as I see fit. If not, my experience and wisdom is being wasted, and the money for my salary or rate is better put elsewhere. Then again, if you have a company that wants to pay you $75+/hour to do maintenance... Let 'em! Enjoy the easy money for as long as it is there. Might want to mention that your abilities are better used elsewhere, but if they want to waste the money on you... Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Maintenance projects are usually harder and unrewarding to work on because most programmers don't write maintainable code. The majority of programmers don't comment adequately (in my opinion), and their code often has unnecessary complexity. Good code is simple and clear.
-
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Christian Flutcher wrote:
I am not enjoying our current C# project which contains 60 projects and not even a single documentation! Do you guys enjoy maintenance projects?
Sometimes. Rapid mass refactoring without a visible safety net is a bit of a speciality of mine. :-\
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
