A situation, that most developers might know from personal experience:
The project is nearing the deadline, and there is far too much work left to be done. Usually the consequence is, that the remaining features of the software will be implemented in a quick-and-dirty way, leaving aside quality related issues like e.g. proper design or adherence to coding standards for the moment. - Much of today's spaghetti code is born this way.
- The common excuse for that is: "We'll do that later. Now our first priority is to meet the deadline." In most cases, this goes with considerable pressure, usually from management.
But the very short answer to that is: "No!" The slightly longer answer would be: "If we don't do it now, we won't ever do it at all. We still can decide to do so, but one has to be aware of the trade-offs that come with this decision."
I don't know how often I heard this notorious "we'll do that later" - statement during the last few years - but I know exactly how often this turned out to be true: Never. It's just not going to happen. When the deadline was finally met, some other (of course very urgent) work will stand before your desk right away.
- Besides the fact that "we'll do it later" actually means "we won't ever do it", there are some other aspects that come with this:
- You agree to deliver a product that does not meet the usual quality standard.
- Changing a system after it was released to the customer is much harder than doing so before the release, comes with much higher risks and for sure produces significantly higher costs.
I don't want to say that the"we'll do that later" - decision is avoidable or even worth avoiding in any case. But everyone who accepts it should know that this is actually a decision not to do something and that there is a price to pay...