1

This question already has an answer here:

I've recently started to work on an old project, that was originally written by two professors with no programming experience. Those professors left the project before they have finished it. Meaning there are many files that no one knows what their purpose, or if they are working at all. In general the code is written badly, got many bugs and many unfinished features, though some of it is actually working good. The new incoming programmers (including myself) are quite experienced in programming, but lack the understanding of what's going on in the project.

I've been assigned to make this project reliable and maintainable in the future, and I'm not sure where to begin. I've thought of going over the documentation and code, and listing the things that I think should be changed. I yet to come up with a better idea.

What would you do to handle this project in the most effective way, while bringing him to industry-standard quality?

marked as duplicate by ratchet freak, Dan Pichelman, Eric King, Bart van Ingen Schenau, John R. Strohm Jul 15 '15 at 18:53

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • This is truly when you need a whiteboard. – chharvey Jul 15 '15 at 18:06
  • I would hire a BA who can get business requirements documented and rewrite it properly all together. – Alexus Jul 15 '15 at 18:44
  • What kind of code is it? What domain (bioinformatics, nuclear physics, quantum chemistry, ...)? Can you still contact the professors (e.g. by email) to ask them some few questions? – Basile Starynkevitch Jul 15 '15 at 19:40
3

I would start writing unit tests -- start with the sections of code that work, write characterization tests that demonstrate (and will help preserve) their correct behavior.

Write additional tests that model how the code should work. Get them to pass, without breaking the tests that are already working.

Once you have a nice suite of passing tests in place, you can start experimenting with removing code you think may not be needed, and see if everthing still works.

  • Indeed, writing unit tests can even expose incorrect behavior ("WTF? Why would anyone want it to do THAT!?!"). – Ross Patterson Jul 27 '15 at 13:56

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