6

Having "completed" my task, I have recently been assigned by my PM to work on a maintenance project by another PM. In this other project, the client wants to add new features and I'm assigned to do a feature.

I'm finding my job over my head for various reasons:

  • code is difficult to understand/read as
    • not well-documented
    • standard naming convention is not followed (seems non-existent, and confusing at times because certain words are used in the wrong way)
    • dead-code
    • redundant code
    • code such as (isTrue == true)
    • temp variables that are not inlined and not prefixed with temp
    • etc...
  • visual sourcesafe is used
  • visual studio 2005 is used, even though they have vs2008 and vs2010. I'm unable to use a plugin for quick navigation (more of an inconvenience)
  • they just want to get things working, without caring about maintainability.

I would love to refactor the code base, and suggest upgrading to svn and a newer version of VS. However, I don't feel that the PM or my new colleagues are amenable to such changes. On top of that, I don't have the confidence of delivering on time (if I'm even able to deliver), and if I do make these suggestions, he may assume that I think I feel that I am superior (not true) and I am competent enough for my assigned task, making it difficult for me to raise issues in the future.

I just don't feel I have sufficient experience yet for a project of this complexity, and will likely end up writing copy-and-paste and googled code with lots of unpaid overtime. I will get surface learning without deep learning, and I feel the entire experience will mar my joy of programming, perhaps making me shun it completely.

In the meanwhile, if I do nothing about it, I will probably just have to slog it out within the current constraints. To this end, I have borrowed books on brownfield application development and visual sourcesafe as references.

What should I do? Should I make my suggestions? How early should I tell him if I don't feel I can deliver? Or should I just slog it out while risking not being able to get my task done?

Improve this question
2
  • 3
    "I don't feel that the PM or my new colleagues are amenable to such changes"?? Why not? When you asked them, what -- specifically -- did they say?
    – S.Lott
    May 17, 2011 at 18:38
  • It's just my feeling that if people don't do something, they are resistant to the idea. (related: see my reply to @DPD below)
    – blizpasta
    May 18, 2011 at 1:51

6 Answers 6

Reset to default
14

Unfortunately more times than not, you're not in the business of writing elegant code, you're in the business of shipping a product.

I'd definitely raise your concerns with your PM. Risk mitigation is a major part of project management and risks should be raised as they're encountered. If you don't raise them, then you're signing yourself up for a death march, for which you would have nobody to blame but yourself.

If there are clear limitations to the current code base, list them all. Highlight points such as why refactoring certain code blocks is necessary in order to implement new functionality. Chances are, if there are no such limitations, you will find yourself having to live with the code as-is. You might want to look into various techniques of working with legacy code and black boxing it as much as possible (i.e. through an adapter implementation or something of the sort).

No matter what happens, you will encounter this type of project numerous times throughout your career (one that makes you pull out your hair). At the end of the day, it only makes you better at what you do. Having the ability to work with horrible legacy code and implement new solutions (using proper techniques) is an invaluable skill and one that many prospective employers look for.

Improve this answer
3
  • 5
    +1 - but don't spend too much time on the fault list, and remember that some of those faults can often be the least-worst solution. I've worked several places where inconsistent style meant you got to recognise whose style a persons code was in - a useful readability clue if you know how those people think. Another unpleasant fact - big code cleanups have a habit of cleaning away complex and "what-the-hells-that-for" bits of code that turn out to be bugfixes that you need to keep. Especially when using Visual SourceSafe, of course.
    – user8709
    May 17, 2011 at 19:15
  • 2
    @steve314: +1 for mentioning "what-the-hells-that-for" bug fixes.. Have seen that a few too many times myself :)
    – Demian Brecht
    May 17, 2011 at 19:17
  • 1
    It's always a little unsettling when you remove a small chunk of code, and suddenly everything works as it should.
    – greyfade
    May 17, 2011 at 20:24
5

For purposes of illustration let's say you have a schedule of 1 month and you estimate it will take you 2 months with no refactoring. There are a few possible outcomes if you refactor first:

  • Refactor time + new feature time <= 1 month. Don't ask permission. Just do it. Not to sound too much like Darth Vader, but the refactoring is implied in your mandate. Of course, follow your normal peer review procedures for design changes.
  • Refactor time + new feature time > 1 month, but < 2 months. Lay out the options for your PM. If they trust you they will go with the refactoring. Make sure you don't take longer than 2 months, or they won't trust you next time.
  • Refactor time + new feature time > 2 months. Tell your PM how much time you could have saved if it was already refactored, but do it the hard way this time. Push to schedule refactoring after the release when there is less schedule pressure.

I just don't feel I have sufficient experience yet for a project of this complexity.

This is your only statement that gives me concern. It leads me to believe you are likely underestimating the cleanup effort. You can work around the quirks now, but if you refactor them, you have to understand why they are there in the first place, and make a judgment call about if the original developer made a mistake or if you just don't understand the underlying purpose of the quirk. Don't go with options 1 or 2 if you're not confident about your refactoring estimates.

Improve this answer
2
  • Excellent rule of thumb. I agree that he is probaly seriously underestimating the clean up effort and should not try to do major refactoring until he is much more familiar with the project.
    – HLGEM
    May 17, 2011 at 21:02
  • Clean-up effort, like everything, is always underestimated. The problem is, if it's a mess already, then there are loads of hidden dependencies. Nearly always, if code needs refactoring then expect to have to refactor significant amounts of code to fix even one method.
    – nicodemus13
    Jan 29, 2013 at 15:48
2

If you are going to make suggestions, and they are accepted, chances are high that you will be the one implementing them, not someone else so make sure you are atleast mentally prepared for the task. Going by your comments you dont seem to be ready so dont go ahead. If you want to do it your next problem is that you are giving up even before you have tried:

I don't feel that the PM or my new colleagues are amenable to such changes.

Ask! What's the worst that could happen? They'll say no. Thats it!

Improve this answer
1
  • You're right, I shouldn't second-guess what they will say or their reasons for doing things.
    – blizpasta
    May 18, 2011 at 1:50
2

When working with a new group the very worst thing you do is come in as a stranger and tell them their code is bad and needs a major refactoring. Who do you think wrote that code?

The better way to approach is to gain a reputation for knowing what you are talking about and delivering the product. Then when you bring up the issues, you have credibility.

There is nothing in what you said that tells me that you are in over your head (i.e. unable to actually understand it and provide a fix however imperfect), just that you dislike working in inelegant code that is not set up to your personal preference.

Consider this, this is a maintenance project - perhaps when it was set up they had no other choice for some of the decisions that they made that you now disagree with. People working with old code tend to forget that choices were made back then with what was available back then and no one has had time to revisit to use newer stuff because that is a lot of work that will cost a lot and insert new bugs for no gain for the user (i.e. no new functionality).

In your career, you will often have to do things the way they want you to do them and not how you would like to do them. That's just the way it is. Once you are experienced and have enough credibility to suggest changes (Becasue you have a good reputation within the organization), you will have more success at changing direction and getting changes in how they do business approved. But you won't by any means win them all even once you are the local expert, so you need to be aware there are times when the conditions will be less than optimal.

I'm not saying don't try to make things better, I'm saying you may still have to work with this stuff as is even after raising concerns.

Improve this answer
2
  • Indeed, I have to be tactful. Most of the existing code is written by the original developers (not here anymore), and the rest by the maintenance team.
    – blizpasta
    May 18, 2011 at 1:25
  • +1 for the first paragraph. I'm guilty of having made that mistake as an intern one time, and I made a few enemies. Since then, I use the "humble, confident, gains respect and then proposes enhancements" and it's working miracles.
    – André Caron
    Jul 15, 2011 at 15:06
1

Definitely raise the issue with your manager telling him that the code is a mess and it will take you more time than assigned to complete the task. Your manager/PM should get the other PM involved and come up with a plan for the feature.

Various decisions could be:
1. Either assigning another developer for the feature
2. Assigning a more senior dev who can handle the task quicker
3. Pushing the date to a later date.
4. A mix of the above 3.

Regarding refactoring, you always have to present good arguments to justify large refactoring work, you should come up with a plan and suggest some low hanging fruit code fixes to improve the code quality, this can be done while working on the feature. Once these are done, you can probably push for further refactoring fixes.

Improve this answer
1

Ask why they're using VS2005 (there may be a good reason for that) and you can try to sell your new colleagues on SVN.

You aren't familiar with the codebase, and you're doubting your ability. This is the exact wrong time to try major refactoring. Many of the things you're complaining about are there for reasons. They may be bad reasons, but you're going to have to understand them before you can make major changes.

You can try to leave the code better than you found it. That which you touch you can legitimately clean up. Just make sure you aren't changing the behavior, since you don't know what odd things in the code are there because they fix an obscure bug (possibly in a bad way).

If you are unfortunate enough to continue to work on this project, you may gain more credibility, and be able to make more changes.

If you have reservations on being able to meet the schedule, talk to the PM now. Explain your concerns. The PM needs to know these things.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.