Unstructured and not-documented software with bugs and problems

Question

Some time ago I started to develop an application. I had to learn how to do it, so I started with testing pieces of code, modules and libraries. From this testing stage I assembled many pieces that worked okay until the application did almost what it needed to do. However, very often I ran into exceptions, bugs, trouble, memory issues etc. To fix things I had the feeling I needed some sort of overall structure in the application to manage modules and so. I thought about using existing frameworks or design patterns. Unfortunately, at this stage I needed to quit the project. Nothing then was really documented and things only worked under very specific conditions.

In the mean time conditions have changed and my memory started to fade a little. The application doesn't work and I'm not sure with modules I still use and which ones were meant for testing. Now there is a new need to finish the application in the least amount of time as possible.

What is the best way to finish this? Which experiences do you have with this?

To be honest, I only see one clear solution:

I can start to reverse engineer the whole application; create UML specifications and other functional en technical design documentation. Afterwards I can split up the application into separate modules, redesign pieces, intensively unit-test them and combine all things together again.

The main disadvantage: this takes a lot of time, maybe more than I spent on the app initially.

Can you give me tips, learn me lessons or anything that might help to end this project fast.

Maybe you have also tips to improve my performance in specifiying the designs, building the app and testing them.

Answer 1

I'm afraid that most of the lessons you are learning will only be useful on your next project.

• Always write simple code. beyond the quote "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.", simple code is easier to reverse engineer and chances are high that you are the guy who will be assigned to maintain the code you had written.
• For the very same reason, always document your code. Explain in comments why you did it the way you did it.
• Unit tests are a great way of documenting code. In maintenance phase, they are a form of requirements that allow you to refactor your code. They need to be maintained as well so don't forget to put comments.

Remember, by doing that, you don't work for others, you work for your future yourself.