16

I'm making little progress on a major project. The source is massive, many layers of objects, macaroni code, double-diamond graphs of multiple inheritance, half-baked features frozen when the original writer left, and no one knows why many pieces of it were designed the way they were.

I suppose any competent programmer would have some trouble figuring it all out well enough to fix bugs, finish the half-baked stuff and add new features. However, I suspect I'm going slower than a typical programmer.

How do I judge whether the source is unusually bad and I'm just doing as well as anyone could, versus the source is typical for a project like this and I'm just slow-witted or underskilled?

Improve this question
6
  • 11
    Understanding others' code is an act of empathy. Forget about how fast you're going and also forget about what a bunch of dumb m**********rs the people who wrote the code were. Figuring it out is an exercise in flexibility. Assume the source is unusually bad, and that you are overskilled, and get back to work and stop screwing around on these stupid forums. Which applies to me as well... I have code to wrangle.
    – Dan Rosenstark
    Commented Dec 9, 2010 at 2:57
  • 2
    Especially forget about "what a bunch of..." when said person(s) are the boss, boss' brother, boss's boss, or boss' boss' nephew, etc!
    – DarenW
    Commented Dec 9, 2010 at 3:40
  • 2
    Ah, the missing "why"'s. Remember to put them in when you figure them out.
    – user1249
    Commented Dec 9, 2010 at 17:56
  • @DarenW - it's spaghetti code, not macaroni code :D (Sorry, I had to).
    – Jas
    Commented Dec 9, 2010 at 18:07
  • 1
    @Jas google for macaroni code... there's more types of pasta than just spaghetti ;-)
    – Jürgen A. Erhard
    Commented Dec 9, 2010 at 19:33

6 Answers 6

Reset to default
6

The only way to decide that question is to acquire a lot more programmers to tackle the same issue and see if they fare better.

This is of course rarely practical, the task has fallen to your good self and providing you are doing the best you can on it, researching where your knowledge fails you. Breaking it apart where the complexity foxes you and keeping whoever cares well informed of your progress. Then I would not worry and keep at it.

Improve this answer
16

First off, I would not spend too much time worrying that you might be "slow-witted or underskilled." Some projects are hard to grasp, and large projects often take a while to get up to speed on. Thinking that you are "stupid" or not up to the task will not help you in any way.

It sounds like you need help with the code, so consider your resources. Do you have access to the original coders? If they are available, they could be good resources for information. What documentation is available? If documentation is scarce, pull out a notebook and start creating your own personal documentation.

The big idea here is that you should expect this process to take time, and the less time you spend mentally beating yourself up, the more energy you'll have to analyze the code and figure it out. Good luck!

Improve this answer
6
  • 5
    +1 It can take upwards of 6 months to really start to know some complex systems enough to be proficient in them. Even if the code base is "good", different developers and teams have different styles, and it just flat out takes time to get your bearings sometimes.
    – Ryan Hayes
    Commented Dec 9, 2010 at 2:29
  • 3
    @Ryan, and 6 months after that, you become part of the problem yourself :)
    – Benjol
    Commented Dec 9, 2010 at 11:11
  • @Benjol Yep, I've been there.
    – Ryan Hayes
    Commented Dec 9, 2010 at 14:40
  • FWIW, when I've been in this boat (several times!), I found it more helpful to take frequent breaks than to just sit and grovel over the code. When you take a break, get up and physically move away from the computer. Stretch, look out the window, think about what you just looked at, then go back and look some more. YMMV, but I found myself making much better progress when I did that. Good luck!
    – TMN
    Commented Dec 9, 2010 at 19:48
  • +1 for creating your own personal documentation. When I do this work, I find making lots of notes (either in the code, or on paper) and drawing lots of diagrams (that usually only mean something to me at the time) helps. An additional plus to all that is the reinforcement of the concepts in your own mind.
    – Andy Hunt
    Commented Aug 23, 2011 at 8:39
6

Ever seen the learning curve. The learning Curce

Theory says that initially it does take time to step up. The trick is to pass the step up point fast. If you are getting stuck regularly then ask for the help from your manager or at least keep him/her informed about the problems you faced. As long as you are ok for schedule no issues.

Improve this answer
2

Dissect it, once piece at a time

Your situation is very common, "getting to grips" takes time as others have already mentioned.

What I find is that if you tackle it "one piece at a time", regardless of how complex a project is you will figure it out. You just have to be logical about it.

Start of with say a button, dig through the source code, put breakpoints, see step by step what's going on. There is two things you need to fulfil:

  • The high level overview.
  • The nitty gritty details that implement the above desired functionality.
  • once you understand parts of it, re-factor it.
Improve this answer
3
  • "One piece at a time" might work on other projects, but this has so many classes derived from others, friend classes, pointers to each other's innards, there are few parts that can be understood independently.
    – DarenW
    Commented Dec 10, 2010 at 16:49
  • I'm sure its a complex maze (something that has "grown" over time). However if you start of with one function, are you telling me you are not able to trace it end to end?
    – Darknight
    Commented Dec 10, 2010 at 21:50
  • Tracing the flow of data, or the sequence of events when for example the user clicks a button, has turned out to be impossible.
    – DarenW
    Commented Dec 20, 2010 at 7:26
1

How about taking a different view: What do you need to know about this code and do you have a way to measure that? For example, if you are trying to fix a bug, that may require a different kind of dive than if you were trying to migrate the code from one language to another,e.g. going from VBScript to C#. If you are trying to get all the requirements out of the current code, that may take a while though I suspect most people would have that kind of problem.

Improve this answer
1
  • I like this comment. One should have a specific goal and work to get that (and only that) goal done. Otherwise, you will get lost in it - Very much like a map thing.
    – NoChance
    Commented Aug 23, 2011 at 12:12
1

While learning something new, many students will think, “Damn, this is hard for me. I wonder if I am stupid.”
Before going any farther, assure yourself that you are not stupid and that some things are hard. …

Mr Aaron Hillegass with the smart words.

You're not stupid, you're not slow, and you're not underskilled. I'm in the same boat, I've come into a new role and the existing code base is incredibly large and shows signs of being repeatedly overdeveloped, it's taken me weeks to get to a point where I feel like I'm even getting close to full-speed. Imagine the project to be like learning an entire new language, it doesn't happen overnight, but takes patience.

Improve this answer

Your Answer

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

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