Know When to Take a Step Back

Painful though this is, it can sometimes be more productive to ditch a dud section of code and start again. The typical reasons and course of action are listed in Table 6-2.

Table 6-2

Dealing with Dud Code

Reason

Course of Action

Programmer has written garbage

Assign work to another

Programmer progressing like slug

Assign work to another

Code works but seriously inefficient

Consider rewrite

Code works but programmer disgusted with their output

Rewrite if time permits

The program partially works

See if it can be corrected

If you find yourself in any of these situations, don't be afraid to appoint a new developer to tackle or rewrite the section. If the original programmer does the rewrite, it usually takes about a third less time than it took originally. If a developer is persistently coming unglued, consider seriously whether he or she is up to the job.

In academia, investigating something for three years and writing a thesis concluding that it doesn't work will almost always earn you a degree. In the commercial world, failure is the last thing that gets rewarded. Remember, though, that some of the world's most successful men and women faced failure before they found success. Indeed, they say failure doesn't deserve the social stigma with which it is generally credited. If you find yourself paddling uphill without even a canoe, call a meeting as soon as possible. If no one has a life-saving solution, try attacking the problem in a different way. A hard decision though it must be, there are times when it makes more sense to stop a project than struggle on.

Here are typical circumstances in which it's best to call all your senior managers together and get a consensus on whether or not to proceed:

♦ The budget is unsustainable.

♦ The schedule is going to miss the window of opportunity.

♦ Key staff are no longer available and it's impossible to proceed without them.

♦ A significant competitor appears.

♦ Technology changes.

♦ You hit bugs that no manner of head banging seems able to fix.

♦ The backer loses faith in the project.

♦ Marketing circumstances change radically.

Because you are regularly communicating with your senior people, the purpose of the meeting is unlikely to be a surprise. If a project has to be stopped, wind it down rather than bringing it to an immediate halt. It is important to find out what components of the project are reusable and document the lessons that can be learned. An aborted project may still justify itself by helping future projects.

0 0

Post a comment