The second way is quick and dirty (QD): you will need only one day to complete the task, but the resulting code will not be very scalable (that is, it will be difficult to extend it to support additional features).
So which approach should you choose? To answer this question we estimate the total development time needed for supporting the extended set of features.
- The ST approach requires 15 days (10 for the initial version, 5 for the extension).
- The QD approach requires at most 16 days (1 for the initial version, then throwing away the code and re-programming for 15 straight days)
But, this is just one side of the story. Here is why you should prefer the QD approach despite this penalty:
- It is possible that (eventually) you will not need the extended features. Thus, you will waste nine days of work for something that will never be used.
- It likely that you can reuse some of the QD code instead of throwing it away. For the very least you can reuse your test cases (remember: we assumed a similar interface). This can dramatically reduce the penalty.
- Getting something to a working state is very important. Other members of your team, who need this class, may have to wait until you finish writing it. Thus, by releasing your class sooner (i.e., choosing the QD approach), you increase the overall throughput of your team. This gain is well worth the QD penalty.
Whatever your final decision is, remember this simple moral: The penalty that the QD approach carries is much smaller than what it initially seems.