Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a small project (3000 lines in Python) that I wrote myself; it has no known bugs and has some decent parts, but is largely a mess because of my lack of time. Unfortunately, I have to be the one who continues writing and maintaining the code.

Is it a good idea to hire a highly experienced developer, explain to them the requirements (verbally, since I don't have them documented), and let them review the code and refactor it (in close discussion with me)?

I am concerned that:

(a) this work is so annoying that highly experienced developers wouldn't want to do it.

(b) I would spend so much time explaining the requirements and what my current code does that it would be faster for me to do the actual work myself.

share|improve this question
add comment

4 Answers

up vote 8 down vote accepted

I don't think it is the right way to go. As you note, explaining the requirements and the current state of the code would already take a lot of your time. Put next to it the time required to understand and discuss the reviewer's findings, and do the fixes in the code.

Moreover, how do you know that the reviewer is up to the task? And how do you ensure that (s)he has a similar way of thinking as you? Without this, the review result may be analog to "rewrite this holy crap, as it doesn't conform to <the latest and greatest programming paradigm according to the reviewer>". So add to the above the cost of finding and selecting a suitable reviewer.

Is it only lack of time which makes you consider this option? Are you otherwise confident of your capability to improve the code to a higher standard?

If so, I would suggest gradual refactoring, as the tasks and future code modifications dictate. It is meant to defeat lack of time by working in small, achievable steps. Improve the code a bit whenever you touch it - over time the small improvements will make a big difference.

If not, you should learn anyway, and outsourcing the reviewing task won't help you in that.

Last but not least: in order to be able to efficiently maintain the code in the long run, you need to deeply know it, keeping a mental model of it within your mind. And the process of building up and maintaining this mental model can't be outsourced.

share|improve this answer
    
That's what I suspected :( And yes, I don't how to tell if someone is up to the task, but I just hoped if someone's very experienced they can review / refactor any code very well. –  max Mar 2 '11 at 17:54
    
@max, in general I tend to agree with that, however I knew a developer who by his own admission couldn't read code well, although he otherwise gave the (not always valid) impression of being very experienced and knowledgeable. So beware of exceptions :-) –  Péter Török Mar 2 '11 at 18:01
add comment

I am not sure what the need for an experienced developer is in here.

3k lines of code is frankly not much, what's stopping you from chopping it off into 10-12 manageable components (classes/methods whatever) for a start and then take it up from there?

And given your situation, I would strongly recommend a suite of unit tests checking out functionality of the individual components.

share|improve this answer
1  
+1 Incremental Revision. –  S.Lott Mar 2 '11 at 19:45
add comment

I would agree with most people that 3K lines of code is not the behemoth you seem to make of it. You could document the logic behind what the code is supposed to do one little thing at a time.

share|improve this answer
add comment

Sharing requirements verbally is never a good idea and just opens the door for miscommunication, errors in implementation and fallout among the parties. Not a pretty picture. :)

Make sure you document things well, and think of it as an investment to your project. It pays off in spades once it's done. Remember that most of the time you are reading code, more than writing it. Make sure things are easy to read, first and foremost.

If you need some guidance on how to refactor properly and change the way you code (no more 3000+ line classes), I recommend reading Clean Code - A Handbook of Agile Programming.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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