Know When to Leave Well-Enough Alone
You have no idea how much time, money, and frustration you will save yourself if you follow this rule.
The standard mode of operation for most programmers has been to stick with a part of an application until it is perfect. This explains why there are so many applications that are 60% complete and hopelessly behind schedule. Of course, the 60% that is complete looks great. This type of approach never worked very well with non-object-oriented programs and, not surprisingly, it doesn't work in an object-oriented environment.
As you are writing your applications, you will find that there are places where the program will not behave exactly as you want. Often, you will find that you need to use a class in a way that it was not designed to be used. One of the great features of object-oriented programming is that you can create subclasses, which will allow you to customize your class to make it do anything you want. This is also the danger of OOP. Tool building can be a time-consuming affair. It also requires that you have far more knowledge of the classes that you are working with. When you write a program using high-level classes, you will find that you can assemble applications quite rapidly if you use the classes the way they were designed to be used. As soon as you start customizing the classes or trying to use them in unorthodox ways, you will find that your application productivity drops significantly.
Before you dive in and start customizing your program or your tools, ask yourself the following questions:
- Is this custom feature essential to the application? In other words, could you deliver it or sell it without the feature?
- Is there time in your development schedule for tool building?
If your application will work without custom changes, the best thing to do is to maintain a wish list. As such items come along, add them to the list. When your application is finished, you might find that you are ahead of schedule. This can happen. Once you have installed the program, you will start receiving real feedback. It may turn out that your user really did not care about some enhancements that you felt were essential. They will probably give you plenty of additional wishes for your list. At this point, you are ready to start your next revision. You can prioritize your wish list, estimate the cost of each addition, and decide whether a particular feature should be implemented.
Building an application is often compared to building or remodeling a house. Just like a builder, you have to have a cost-effective method for handling change orders. As an OO-builder, you have a big advantage over a home builder. The home builder must often handle change orders while they are doing the original work (it is too expensive to go back and make changes in a completed building). You can build your entire application and add the changes during the next revision. This provides a very powerful way of controlling costs and delivering product on time. Use it!