It is our first game and we are a start-up. We had a programmer who suddenly is seeming to be a dead weight. Though we knew him personally we thought that he was as motivated as we are and hence I never looked for a code review or documentation. Now it seems that he is slacking a lot and we want him out.

Now during a conversation he said that he would not document the code so as we could be dependent on him. I looked at the code and there is no documentation.

The code is all over the place. What would be the best way to understand his code?

Details of the code:

  • Written in C# and targeting a mobile platform using Unity3D.
  • The game play mechanic and camera is scripts are the main and they have no documentation.
  • Too much of Send/Broadcast messages so I am not able to see the references through Mono.
  • Again hefty use of strings in either invoking methods or passing parameters
  • Update function everywhere which could have been reduced to coroutines.
  • Naming is poor and inconsistet
  • Absolutely no pooling with usage of destroy and instantiation. I am expecting memory leaks.

What protocols should I adopt to understand the code and work on top it?

  • 2
    related: programmers.stackexchange.com/questions/155488/… Commented Apr 22, 2013 at 18:48
  • Just curious, did he ever show you a working app?
    – JeffO
    Commented Apr 22, 2013 at 19:11
  • 1
    Code review and documentation are not things that you do to motivate programmers. They are part of a normally functioning team. That's your first mistake. But listen, if your question really is How do I understand code that has no documentation? I have, I have an answer for you.
    – Kazark
    Commented Apr 22, 2013 at 19:14
  • @Kazark but then it would be a duplicate of the question I linked... Commented Apr 22, 2013 at 19:28
  • 2
    I recommend that you start reading up on how to run a software team real fast. At this rate your startup will not last long.
    – Kazark
    Commented Apr 22, 2013 at 21:28

5 Answers 5


What you need are Characterization Tests.

A characterization test is a test that characterizes the actual behavior of a piece of code. THere's no "Well, it should do this" or "I think it does that." The tests document the actual current behavior of the system. (Feathers, Working Effectively with Legacy Code, 186)

You can use characterization tests to develop documentation for the code after-the-fact. This is not the preferred way of doing it, of course; it is better to write tests before writing code. But when you are dealing with a legacy codebase (and according to Feathers a legacy codebase doesn't have to be old—a brand new codebase has the same characteristics as an ancient one if it does not have tests) characterization tests are a great boon.

Feathers says (186):

Here is a little algorithm for writing characterization tests:

  1. Use a piece of code in a test harness.

  2. Write an assertion that you know will fail.

  3. Let the failure tell you what the behavior is.

  4. Change the test so that it expects the behavior that the code produces.

  5. Repeat

Note that these tests are different that regular TDD tests in that they are not intended to describe what the codebase should do. They only describe what it does—which is exactly what you are wanting to determine.

If, of course, you find that it does something wrong, you now have tests that allow you to change this behavior with TDD. You change the test to expect what you actually want, and then fix the code until it does that.

Feathers has quite a detailed treatment of how to write such tests. He also discusses in other parts of his book how to get the code into a test harness in the first place (and thus he assumes it in step #1 above) but that goes beyond the scope of this question.

  • @karark I appreciate your input for this question. Great INPUT and help. What is test harness actually mean on this context. Could you please elaborate a little bit. Thank you.
    – Filip
    Commented Apr 23, 2013 at 3:44
  • 1
    @karsnen You're welcome. To have a test harness around some code means that you are able to isolate that piece of code from the rest of the application and automate testing of its inputs, outputs and effects. By automated I mean that the test simply reports pass or fail without requiring manual validation. (This can be no small feat in legacy/poorly written code.) In additional to Michael Feathers' book, Roy Osherove's book The Art of Unit Testing is very good; I think the next edition is about to come out.
    – Kazark
    Commented Apr 23, 2013 at 5:31

Throw it out and start over.

  • It's impossible to write code that other people can't follow that you yourself can follow. Or that is even good. The code sounds not worth maintaining based on your few lines of description.
  • Sounds like the kind of person who would leave logic bombs. Do you want to defuse them?
  • Sounds like you're about to greatly underestimate the cost of maintaining software.
  • Fire the employee ASAP. He's already voiced that he thinks the best way to grow in the firm is to contribute as much negative value as possible. He is working at negative value currently.
  • I believe my answer is best for the abstract question "What is the best way to understand code in a project with null documentation?" Yours is probably best for his situation (it's not a system people have been depending on for years). +1
    – Kazark
    Commented Apr 22, 2013 at 21:30
  • We are going to diffuse him. I did greatly, GREATLY underestimate the cost of maintaining software. We are about to fire him but going get legal a bit. Talked to a lawyer. Appreciate your help.
    – Filip
    Commented Apr 23, 2013 at 3:37

Sounds a lot like a project I've been working on for a while. When I was hired for the job I currently work at, I was given a folder on the desktop of an old machine and told that it was probably the most recent version of the code for a website. No documentation, code copy and pasted everywhere, some of the business logic in code, some of it in stored procs in multiple databases, etc. On top of that, the person I was replacing was the only person at the company who had touched that code so no one could really help me.

I'm still working on bringing that code up to some measurable level of sanity but this is what worked for me.

  • Play around with the project: I just took a tour through our site (thankfully we had a beta environment I could do this on without fear of corrupting data, etc). I clicked around, tried using different features etc. I also looked at the code a bit while I did this so I could get an idea of what was where and how it worked.
  • Fix a small bug: I started out with some small bugs and tried to fix them. It took a while to actually fix them, but I got more familiar with the system as I went. After a while it became easier and easier to find things and to understand the code. It's still not a pleasant task to work on the code, but it has gotten easier.
  • Keep at it: It's not an easy thing to work on code with no help, but it does get easier.

TL/DR: Get a test environment and start messing around fixing bugs and playing with your app. Don't give up, it will get easier.

  • Experience teaches a lot, I guess. I just have to think that this is easy stuff. I am going to learn a lot in the next few days.
    – Filip
    Commented Apr 23, 2013 at 3:38

What I would do is sit down at the keyboard, invent a problem, and try to solve it -- that is, pick some part of the app and try to modify it. It doesn't really matter much what you try to change -- the act of digging deep into the code to make the change will force you to confront all of the bad coding practices as you try to understand them.

Dedicate lots of uninterrupted time to this task because you'll need to get a little flow going. You'll probably have to juggle lots of things in your head until you understand it all. Don't take the problem lightly -- it will take lots of concentration. Accept it as a professional challenge, and dive in head first.

I had a similar problem once, a long, long time ago. It was some gnarly database code written in fortran, by someone who I think only knew fortran-66. It had some nasty bugs that had eluded several people. I dove in, and I kept a log. I wrote out my thoughts as they happened -- "oh, variable FOO is both a local in this spot and a global in that spot", "this class is never used", "this is sometimes called with three args, sometimes four, and the fourth is never used", etc. This really helped as I slowly discovered the madness within.

It took me a few days, but I finally nailed it.

And talk to a lawyer. It sounds like you're being blackmailed.

  • Bryan - We are going to talk to a lawyer for sure. Tired and made mistake which WE (my other artist and myself) would not like to repeat again.
    – Filip
    Commented Apr 23, 2013 at 4:03

very simple?
I would just use the code and refactor/rewrite parts of it that need a change whenever it's necessary.
You don't need to rewrite all his code if it just works.

Coming to think about the fact that he may be THAT Kind of coder,
There may be a few solutions that may be impractical but they may be worth mentioning:
1.hire an ex-coworker of his that knows his coding style.
2.hire someone that doesn't comment his code, this kind of people understand each other best.

  • reason for downvote?
    – Behrooz
    Commented Apr 22, 2013 at 18:52
  • 1
    There's a good chance, if he is that kind of coder, that a good part of his code doesn't work. Until you can test it/understand it, how do you know? "Just works" is a bit of a myth.
    – Kazark
    Commented Apr 22, 2013 at 18:57
  • @Kazark I didn't think he may be that kind of coder. now that you mention it, i guess i have another solution.
    – Behrooz
    Commented Apr 22, 2013 at 20:35

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.