• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Would You Resign If Code Is Unmaintainable?

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would you resign if the code is unmaintainable?

1. No comments or javadocs.
2. No design methodology.
3. Boss doesn't know or appreciate a singleton, factory, or even what is the meaning of encapsulation, coupling.
4. Boss only cares on the bug or feature added. He doesn't want to know about how to do unit testing, defensive coding.
5. You're just as appreciated as the the junior programmer.
6. Code looks like C disguised as Java.


Even after you've spoken up that there needs to be coding standards, design documents, etc. and he won't listen to you.
[ August 08, 2007: Message edited by: David Aslan ]
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my case also, same is happening. However my boss is not technical guy but functional guy. Mine is a small firm and I continue to work as I learn how to deal with such management team. When I speak complex jargons, he certainly gives time for my task and that helps me a lot. May be, he appreciates implicitly.

In most of cases, real time customers demand features like that.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, if there are other jobs which are easy to find out there, there is no reason not to quit. However, dont quit till you find another job...This is what I would do.
However, I personally would need more reasons to quit a job. Unmaintainable code is not enough, if the manager is hostile, colleagues are difficult to work with, etc etc, then yes, I would start thinking about getting the hell out of that place.
 
Ranch Hand
Posts: 1140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Aslan:
Would you resign if the code is unmaintainable?



No I won't. I will try to make it maintainable.
Regarding your issues - been there & seen that. But what I don't understand is - why do you need the approval from your boss to make it better?
Does he tell you not to add comments to the code? What is stopping you to add little comments / Java doc when ever you add a feature or fix a defect?
Cleaning a code need not be done as a task in it's own. You can do little everyday and the code will get cleaner, eventually.
 
Ranch Hand
Posts: 1704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Mani Ram. There is no guarantee that you won't see this kind of problems at your new job. If you feel something your missing in your project try to convince your boss if not try to adjust but leaving job may not solve the problem.
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Aslan:
Would you resign if the code is unmaintainable?



Of course not. If you resigned every time you encountered a problem you'd never last in a job. The only time to quit is when you have a serious problem which impedes work/success and will not be given the support (tools, time, help, etc) to change it.


Originally posted by Shankar Sidhaarth:
However my boss is not technical guy but functional guy. ... When I speak complex jargons



If you boss is not a technical guy why would you ever use "complex jargons." You should speak to people in a manner they understand, not in a manner only you understand.


--Mark
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A Great question, and real situation.

Mark Herschberg is right on the money!

Mark Herschberg

quote riginally posted by David Aslan:
Would you resign if the code is unmaintainable?
Of course not. If you resigned every time you encountered a problem you'd never last in a job. The only time to quit is when you have a serious problem which impedes work/success and will not be given the support (tools, time, help, etc) to change it.



The real reality is that a large percentage of code is written that way. I do what I can to change it as I encounter it, but it's a skill to track through bad code. Unfortunately no one may know what you are doing but you.

Sadly I can only say get use to it and be an agent for change. The sad fact is that alot of Java developers are translated C,mainframe, procedural developers that have not yet embraced the theories of Object Orientation and Unit Testing. I am looking at a 4,000 line class yesterday to transform XML- not one unit test! Hey think of it this way, we have the opportunity to educate them

5. You're just as appreciated as the the junior programmer.


producing well functioning code is the best way to graduate from a Junior position. Code Structure and Unit Testing will help in the endeavor.


Remember, at the end of the day, you should be happy. If that does not change, it's time for a change in jobs. But you will see this type of code/environment again. REAL SOON! I see it very very often, even at big companies with a full Software development life cycles. Disgusting!

Assume the position ... and ... best of luck.

Cheers...

Tony
Sun Certified Web Business Component Developer
Sun Certified Web Components Developer
Sun Certified Programmer for the Java 2 Platform
 
Ranch Hand
Posts: 201
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are in a lose lose situation in my opinion. If you quit you will be a quitter and a person who can not work through tough situations. What will you say at your next interview when the interviewer asks why you left your previous job? you can't say because 'their documentation sucked'.
At the same time if you stay there, you will be trapped at a company with bad programming practices and most likely bad software/products. You likely will always be behind because you will get new assignments yet have to juggle them with the duty of cleaning up all the bad code. And if you ever have to reference some older code you will waste time trying to figure out what you are looking at because there is no documentation/comments. This will affect the time you can put into your new code and thereby probably hurt the quality of it.

I suggest you just keep bugging the boss and hope he realizes that the company practices need to improve to increase the productivity of the developers there.
 
Marshal
Posts: 28175
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me make a comment that is only partially related to your question: Code maintenance is an honourable profession. There are far too many people that spurn maintenance in favour of new development, and this is a harmful situation. First bad code gets written, because 90% of code that's written is bad code, then nobody wants to work on it so they write their own (bad) code and the cycle is perpetuated.

The world needs more maintenance programmers. So get into that code and fix it and take pride in that. You think there should be unit tests? Make some. You think the code needs to be refactored? Do it.

Yeah, I know. The boss won't like it if you take a week to make a change that the original programmer could have hacked into that code in ninety minutes. So you can't do a lot. But the boss can understand that it might take you a day, because you didn't write the code, even if it would really take you only half a day to do the hack. Use that extra half a day to do a little bit of cleanup. Maintenance is a long-term process and it always needs to be done.
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
David, I would not quit based soely on these points. I would look into finding new work. but ....

You need to also consider:
  • How much $ will you gain/loose by jumping ship.
  • How much additional time will you spend in commuting to the new job.
  • the availabilty of other work in your area
  • the possibilty of relocating. impact on kids/wife/dog/cat....friends/parents
  • Even if the coding practices are bad. Are they using new or old technologies. Eveng bad coding in a J2EE5 shop dong ejb3, hibernate, JSF, web services, ajax, ..., on websphere/weblogics is far better than wonderful looking code on a 7 year old code base.
  • Can you influence the boss or his superiors into better practices?
  • Is the company bound by some SARBANES-OXLY, ISO, FDA, DOE, ... constraint. You can legitately argue that poor practices will lead to more frequent violations of various regulating rules. my managers have told me that SARBANES-OXLY has given investors the right to quality product from the company and that I as an employee must protect the investors rights. (as much as I hate attorneys. they are sometimes useful)


  • Originally posted by David Aslan :
    Would you resign if the code is unmaintainable?

    1. No comments or javadocs.
    2. No design methodology.
    3. Boss doesn't know or appreciate a singleton, factory, or even what is the meaning of encapsulation, coupling.
    4. Boss only cares on the bug or feature added. He doesn't want to know about how to do unit testing, defensive coding.
    5. You're just as appreciated as the the junior programmer.
    6. Code looks like C disguised as Java.


    Even after you've spoken up that there needs to be coding standards, design documents, etc. and he won't listen to you.

    [ August 08, 2007: Message edited by: David Aslan ]




    I have worked in several shops with "unmaintainable code" They are sources for long term employment. The only shops I automatically walk from are ones where everything is an emergency and there are at least 3 emergencies a day (including weekends). Yes emergencies happen. Yes you may have to work night and weekends. But everyting looks like an emergency to a bad manager.
     
    David Aslan
    Greenhorn
    Posts: 13
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think in the end the following factors are the thing:

    1. You want to refactor. But your boss doesn't know what refactoring is, in fact it appears to him you are actually slower than other people who can fix it in 90 mins when you take 1-2 days to refactor and test. In fact because the code is so spaghetti and macaroni like you are risking even more problems cropping up and looking bad for introducing new problems. So in the end you don't refactor and just hack it.

    2. The boss doesn't also want to refactor because though the program is buggy, the status quo is that those bugs are tolerated. He just doesn't want to see new bugs. So there's another roadblock to cleaning up code.

    3. Adding comments is alright. The thing is it's just for you. You won't be appreciated for it. Nobody cares about the comments except you.

    4. The economy is doing so well, that people are willing to hire you even if you've been in the job for 3 months.

    5. There isn't any joy in hacking code. It's like you're a great mechanic that was hired to work in a really unorganized garage and the foreman doesn't want you to tidy anything up. You may clean up your own work area but because you're dependent on other places that are so disorganized it's not really fun working in that environment.

    In think my conclusion is to act responsibly and to warn but if a ruler does not heed dire warnings, he lives and dies by the effects of his reign.

    The attitude I think is to work well and do the best NOW. Take the lessons learnt. Make sure you don't commit the same mistakes as them. Journal them, it would make a good speaker story in conferences.

    I think in the end, bide your time, do your best in whatever circumstances, and keep a lookout for better opportunities.

    Leaving is never a good option for the sake of leaving. But leaving for a better destination is right.

    Don't resign but realize that there are better pastures and that other people are willing to pay even more for your skills. People who don't appreciate you and don't reward you or support you are just shooting themselves in the foot. If you're really good, you will be hired by better people.

    In the meantime, continue upgrading yourself, get certified, network, even contribute articles, freeware on sourceforge, etc. 80% of your career is not controlled by your boss, but rather you and you taking advantage of market forces.


    "Do you see a man skilled in his work? He will serve before kings. He will not serve before obscure men."
     
    v ray
    Ranch Hand
    Posts: 223
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Well summarized! Good luck with your job, I feel your pain as I'm in a very similar situation, but I'm trying to make the best of it and come out of it all a better man.
     
    Ranch Hand
    Posts: 10198
    3
    Mac PPC Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by David Aslan:
    Would you resign if the code is unmaintainable?



    NEVER. I close to such a situation. The code that I'm working with is maintainable but hard to understand the flow as there are no design docs or feature functionality docs and this has been in production for more than 10 years. I'm definitely trying to make the best out of it and achieve my task. It's after all the challenge in programming.
     
    Bartender
    Posts: 2661
    19
    Netbeans IDE C++ Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Respect to Jothi. That's the spirit.

    Regards, Jan
     
    Ranch Hand
    Posts: 376
    Scala Monad
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I want to add my 2 cents:
    Currently I have to deal with ancient java code to do some fixes and small enhancements. First I thought "boring stuff, hope it ends soon..."
    But working with the code, I introduced JUnit tests to the team resulting in (almost) zero defects; using refactoring, I transformed the spaghetti into a more elegant design reducing the code size to one third; and by rewriting the database access I had a 900% performance improvement (almost 10 times faster!).
    I'm getting deeper insights on refactoring and unit testing, I'm pretty satisfied with the results, and the managers are delighted!
    It's a "win-win" situation!
    (anyway, I'll go back to design new systems ASAP)
     
    Ranch Hand
    Posts: 154
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I was in an exactly similar situation while working for one of my previous employers. We were a team of just two people and were assigned the responsibility of enhancing a dismally written product incorporating multiple features and drastically improving the performance.

    In the process of developing the features, to our utter disappointment,we gradually discovered the gross and easily avoidable inefficiencies built into the code with literally little or no object orientation,extremely poor modularization ( methods running upto 1000 lines with same chunks of code written at numerous places).

    Secondly, the feature enhancements were specifically targetted at a particular customer, the data transactions of which were just impossible to manage with the existing data access/update logic implementation.In other words, the product was just NOT scalable at all.And redesigning the data access/update logic everywhere to achieve the desired level of performance,besides making the code more modularized, readable,and Object orineted looked like a mammoth task,especially considering the resource constraints( We had to drive the customer to production fast).We felt really let down by our boss's decision to make us work on such a thing. At the same time, we felt happy about being awarded the responsibility of carrying out this extremeley challenging (at least so it appeared)piece of task.

    What did we do? Did we quit grumbling about the pathetic and seemingly incorrigible state of things? NO,we took the crisis as an oppurtunity to turn things in our favor and went ahead with full passion.The result? Similar to what Grabiel achieved. The product not only scaled but also became aound 900-1000% more efficient.

    So as most of the posters have advised,take this as an oppurtunity to make things better unless you have more compelling reasons to consider giving up.

    good luck
    [ August 27, 2007: Message edited by: san ban ]
     
    Ranch Hand
    Posts: 343
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by san ban:
    NO,we took the crisis as an oppurtunity to turn things in our favor and went ahead with full passion.The result? Similar to what Grabiel achieved. The product not only scaled but also became aound 900-1000% more efficient.



    Perhaps I'm being overly pedantic here, but by definition the code was maintainable, since you got it to work and achieved good results.

    Personally, I'd be more curious as to the responses if one was placed in a situation where one was incapable of fixing the code, due to some combination of excessive complexity combined with management (or other team members') refusal to make the investment in a significant refactoring.

    Cheers!

    Luke
     
    Gabriel Claramunt
    Ranch Hand
    Posts: 376
    Scala Monad
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Luke Kolin:


    Perhaps I'm being overly pedantic here, but by definition the code was maintainable, since you got it to work and achieved good results.

    Personally, I'd be more curious as to the responses if one was placed in a situation where one was incapable of fixing the code, due to some combination of excessive complexity combined with management (or other team members') refusal to make the investment in a significant refactoring.

    Cheers!

    Luke



    Probably you are overly pedantic (just joking). To be more pedantic, if you can maintain the code, is by definition is maintainable (in the same way if you are flexing a steel bar, the bar is "flexible"... )
    In my case the code was pretty much hard to maintain, the same unmaintainability allowed me to invest time on refactoring it, because nobody expected a quick fix ("hey it's hard to maintain! any change or fix take time!..." meanwhile you refactor as much as you can). Refactorings aren't perfect and you can't get a great design by applying them alone, but they work great to transform spaghetti into something you can work on.
    Of course, maintaining code sucks pretty much, and I'm only doing it because is a special situation. I was trying to convey the idea of transforming a seemingly bad situation into a good opportunity. I know that's not always possible.
    Maybe in a different situation I would resign... I don't know. Strangely enough, the only time I was close to resignation was in a development project and not maintenance. Anyway, the main motivation for any highly specialized occupation (like programming) is the work itself, if you don't enjoy what you're doing, try to find something else either in the organization or outside it, because if not, you'll be miserable...
    In other words: if you have to maintain a horrible code, your team sucks,and your boss is a jerk, don't waste your time and get the hell out of there! And ask yourself: how you ended in a place like that? Next time, do some research before saying yes!
     
    Ranch Hand
    Posts: 365
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Its tempting to read other's replies first but I chose not to this time..

    I did!!

    I waited for one year.. tried to get my point across.. provided industry standards and widely accepted reasons for my suggestions..

    but the trouble was seen not only in code and its documentation mentenance but in the minds of the people in that particular company..

    Same frustrations were amongst the lateral joinees in other projects also.

    Thereafter, to be frank, I have admired and made the best out of all the freedom to make mistakes and improvements in my newer companies.

    I guess..something like.. if you have worked in hell, you appreciate working on earth!
     
    Author
    Posts: 3473
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    It is very hard to progress in this kind of environment...... seniority and salary should not be always attributed to just how many years of experience you got or where you worked in the past(small company or a big company). What really matters is what you did in those years?, how much value you did add to the project?, how much you learned?, how pro-active and passionate were you? etc. If your superiors cannot see this then there is not much chance for you to progress in your career. You become just a number.
    [ September 06, 2007: Message edited by: arulk pillai ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic