I am getting married soon and for that I had to design a proper settings arrangement.

I started by writing names down on a paper. But after a short time I only had a sub optimal solution, so I started to erase names. Very shortly after I had a big mess but no seating arrangement. I then thought hey when I have software probem that is hard to grasp I get paper, pen and scisors and make a paper prototype or CRC cards. So I put the names of the guests on pices of paper and aranged them aound paper tables on the floor. The advantage was that you could swap and move guests around easyly.  I finally got a seeting arragement in under 10 minutes…

On think I learned was: paper prototypes are also good for real life problems.

Cyclic dependencies are a challenge for any build system and code to handle. But I you look closely at cyclic dependencies, in most if not all cases they are a structural problem and not a technical problem. Cyclic dependencies indicate in most cases either that two modules belong together or one module implements two tasks.

Let’s take a projcect I am currently working on. There are two modules, the Interpester and the Object Manager, both are cyclic dependent. The Interpreter implements a virtual machine. The Object Manager implementes object serialisation and low level buissness logic. The basic contollflow is as follows: Object Manager calls Interpreter to evaluate some value and to do this the Interpreter calls back into the Object Manager get values to a given object.

If you read the above paragraph cloasly you will notice that the Object Manager implements “object serialisation and low level buissness logic”. Well as you can see there are two tasks that can and should be split in two seperate modules. If they are split in three modules there are no cyclic denendencies.

Working with legacy code can be frustrating and often you might want to scrap everything and rewrite it. Many projects try this and in almost all cases they fail at it. They have a really hard time, because the problem at hand was not as simple as it seemed.

What people ignore is the fact that the code contains a large number of little bits of knowledge, quicks of the system that are not obvious. This knowledge was gained though long years of maintenance and the inherent problem is that this knowledge gets lost on a rewrite.

On the other hand, legacy code can become a maintenance nightmare. Something has to be done to improve code quality, rejuvenate the code and thus reduce the maintenance burden.

The solution is to make many small changes and improve the code quality day by day. By refactoring the existing code the knowledge within the code is not lost and you have a running system all the time.