- Solve the Business Problem now, if there are technical issues that will take a while to resolve, solve them later.
Obviously, there is certain conditions that should be met, such as solving the business problem with some architecture/engineering to help with maintaince issues, changes, etc - but the point is to not over-engineer, and not to wait for a technical 'fix' unless it is clearly within the timeframe to solve a business problem or would impact the quality of the business solution to solve said business problem.
Cost: It *will cost more* to solve the business problem now and take care of technical issues later. This is where most management and customers do not really want to hear and, frankly, usually do not care as long as the business problem gets solved.
Revenue Stream: However, as a technical representative to an organization, and more importantly as an employee or consultant, the sooner you can bring in and/or maintain the revenue stream, the better overall for the organization. This may or may not cover the additional cost associated with the above statement, but quicker time-to-market is usually a good thing as long as the quality *of solving the business problem* is not compromised.
Why this rant? It's not a rant, it's been a thorn for a lot of individuals and teams. Some people are very good at the so-called 'quick and dirty' solutions that get something up and running, then spend *enourmous resources* maintaining that solution. Other over-engineered solutions may miss deadlines/over-budget but once deployed *may* cost much less over time (TCO) compared to an equivalent quick-and-dirty solution.
There is no perfect answer, other than no matter what a technical project will have costs during development and costs for maintanence -- but it has no value unless it solves a business problem.