CTO? info to make you think

One day soon, (or maybe this just happened?) a young, slightly warm person, will show you an image not unlike the one you see here:

The person will smile quite a lot and wave their hands and point out boxes in an enthusiastic manner. At the end of the session, they will say that there are obviously a few small problems and that the new upgrades you asked for will need a few more weeks or months of work. Then you'll pick up your phone and call someone like me to come audit your codebase and see why there are problems.

The person like me will arrive and spend a week looking intently at the screen, searching the code base, looking at your code and you will ask for a quick fix whereupon the consultant will show you that rather than the lovely diagram above, your code actually looks similar to this:

This is the typical picture that is seen in software projects in which the words "Quick Win" or "Fast Response" are used as design criteria and where the manager of the project says that "Testing uses resources that might otherwise be used to generate code" or that "We must be agile" where agile means an ability to change things quickly, in other-words to claw yourself out of the large hole you just spent five years digging for yourself.

The only way to prevent this from happening to your code is to place as much value on software quality and understanding your code as you place upon the product itself. Code quality assurance costs you money in the short term but will save you your job in the long term.