Making an effort: develop it right

Even after so many years programming I still find it a shock to sit with someone and they immediately want to cut corners. Without the any immediate deadline and pressure to want to hack something out so it works then leave it to rot. It is maddening to come to a system that a buiness has spent a fortune redeveloping only to find it's no more maintainable than a legacy solution. There are a number of reasons why developers might be encouraged to throw a solution together:

It's a throwaway script
No matter how temporary a program may seem it is worth doing right because temporary fixes have a habit of staying round for a long time. Even if you are never going to work on the program again, there is a kind of Karma involved--- you should leave the code how you'd expect to find it. Don't speculate the solution will not last too long. This question was addressed in a column for the Communications of the ACM, George V. Neville-Neil writes:

Computer programmers and engineers are in a unique position when it comes to the work we do. We are both scientists, dealing in the abstractions that help us solve problems as well as craftspersons, turning those abstractions upon our modern lathes that help make the modern world what it is. When we craft our code well it works more effectively and more beautifully, helping to create better systems. When we rush the job, and ignore the nicks and scratches, the parts fail to fit and eventually we’re left with software that looks more like that fort you built in the backyard when you were a child. Sure, it was fun to hang out in that fort, but you ran back to the house at the first sign of a real rainstorm.

One exceptions is Architectural Spikes where technology is first tried to test it's viability before developing the system.

Tight deadline on a production system
Outage is can be expensive, and doing the quickest thing to get the system back on line often requires the software equivalent of duct-tape. Duct tape in the real world is used in a crisis, once the crisis is over then a real solution that will stand the test of time will be found. A famous example, that may illustrate this, is the building of an air-filter on Apollo 13. These air filters scrub the air to keep it breathable by removing the CO2. NASA certainly would not have sent the mission up with cobbled together filters, it's only after complete failure that a temporary measure was taken. There is an equivalent to software duct tape in live environments but the cost to make sure that a solution that has some longevity is important.

It is time consuming
Developing good software is time consuming. Cutting corners to meet the market can be counter productive and a false economy: if a new product is not developed to be maintainable when the product does take up the development team can struggle to meet demand. One reason to develop software well is that it is extensible and stands a better chance of remaining defect free. This is especially true of testing. When systems are developed alongside their tests, and the system is structured to be testable, then regression-testing and releasing happens much quicker. Some years ago I worked on a system where all testing was done by hand. The customers would scream for features, developers would struggle to add changes without introducing defects and the whole development cycle slowed down. Spending some time up front on good development means the business remains viable.