Cure

---

You have fallen victim to Myopia or are stuck with the result of someone else’s Myopia. What do you do now? The first step is not to panic. You will need to step back and look at the situation with a clear mind in order to decide the best course of action.

Refactor

First, consider refactoring the current code to remove the problem introduced earlier. Refactoring is a natural part of software development, but in this case, it might involve some extra work that could have been avoided. Nevertheless, if it must be done, it can still be done in a controlled and orderly fashion to avoid introducing more problems instead of fixing the existing ones. Once again, the key is not to panic.

First, decide what changes are required to get development back on track. Remember to account for any functionality that might be required later in development; otherwise, you will only be fixing a myopic problem with another myopic problem that will hit at an even more critical juncture in the project. Analyzing the problem and coming up with a solution is also a good break that can help to calm your fears so that you do not attempt to hack a solution.

Once a design is in place, the refactoring can begin. Refactor in small steps and test thoroughly as you proceed. This is always important in refactoring and prevents the introduction of more errors while you are attempting to solve old ones. Discipline is the key here to avoid rushing in a poor solution, especially if deadlines loom. Rushing might allow you to meet that deadline, but it also increases the chances that you will miss the next deadline by an even greater margin.

Sometimes you really do not have the time to refactor and still meet all of your deadlines. This is the time when you must confront the decision on whether to give up features and simplify the goals of the project, or to extend the completion date of the project to keep all the features. As we just discussed, do not try to trade out the necessary time for refactoring just to keep a feature. If you do this, you are likely to lose more than just the one feature.

Reboot

Sometimes the result of Myopia is such a complete mess that it would take months to sort through and refactor the result. This is when you must step back and consider starting from scratch. Starting over might seem like it will only cost you more time, but when the alternative is reworking a piece of code that does not do what you want it to, it can be the best option.

This is always a judgment call that must be made on basis of an individual occurrence. You must estimate the amount of functionality that is similar to the desired functionality, and how much must change to meet the new requirements. You need to then estimate how long it would take to make these changes, keeping in mind that changing code requires more care and testing and therefore more time than writing new code. Now compare this to the time estimate for writing the functionality from scratch. This should give you an indication of which path to choose.

Avoid Crunching

There is another solution that comes up when a decision must be made between dropping features or pushing out the deadline when the result of Myopia is encountered, and that solution is to work long hours. Often known as “crunch time,” this method of development has more disadvantages than advantages if used for more than a short period.

First, overworking can cause programmers to burn out or quit, which certainly does not help the effort to finish the project. Even if the programmers stay for the length of the project, chances are good that they will leave at the end of the project with all the knowledge and teamwork they have developed. This represents a loss that is often undervalued. The knowledge and skill of a good programmer is worth far more than technology.

However, if you are a programmer on a team and you must convince management that extended crunching is not a good idea, telling them that they will lose you is not the best first approach to convincing them. A better argument is that extending crunching does not work. The expected benefit of having programmers work extra hours is that the software will be completed faster. Unfortunately, the ratio of bug-free code to hours worked does not scale well for most programmers. As programmers work longer hours, they lose energy and concentration. Thus, they are more likely to introduce bugs as work goes on, and these bugs must then be fixed later before the implementation can be said to be complete. At some point, the time required to fix the bugs introduced in an exhausted state will exceed the time saved implementing new features. Crunching results in no gain or, even worse, in longer development times instead of shorter.

---