The evil of process over craftsmanship

If you had a choice between a well build home that cost more money but wasn’t going to cost very much to maintain or a house that didn’t cost very much, but was going to cost a lot more to maintain in the long run, which would you choose.  If you own a house and have had to deal with the upkeep of the home I can almost guarantee you would much rather have the first house, even if fixing the major problems is free (most new houses come with a one year guarantee from the builder), if you have ever had to deal with getting your builder to fixed things, free or not, the stress and aggravation almost makes it not worth it.  So why do so many software development teams almost insist on building software like how the second house was built.

By taking the time to build a quality product, it will cost more up front, talented people cost money, to do the job right takes time(time=money) but because it was done right the first time it costs a lot less in the long run. 
Unfortunately in the software development world it’s far to common to just get it out and worry about fixing known problems later.  This becomes even more painful when the schedule or process becomes the reason for poor craftsmanship.

Here are two problems, one is building a house the other is building software:

1) A builder starts working on a house and discovers that the property has a high water table and that every spring there would be flooding in the crawlspace.  The two ways to solve this problem are: bring in enough dirt to raise the house up so the crawlspace doesn't get flooded or add subpumps to pump the water out.  Both fix the problem, while the subpumps are going to be quicker to setup, it’s not going to get out all of the water and it will add to maintenance costs which in the long run will be much more expensive.

2) A pair of developers are tasked with writing a service for importing data into a database and half way though writing it they find out the data has duplicate records and some other garbage data.  There are two ways to solve this, build a validator to remove the garbage data or pass it off and have the DBAs create a job to remove the garbage from the database.

I’m fairly sure we would all much rather take the time to put in the fill dirt then have to deal with the maintenance of having sub pumps, and yet for some reason it’s very common for developers to be told “we don’t have time to add a filter” and to push the task of removing the garbage from the database onto the DBAs, or worse yet just live with the garbage data.

We know that when the process(schedule/tasking) trumps craftsmanship(using subpumps or having the DBAs remove bad data) you end up with a lower quality product with higher overall costs so why do we still do it?
The tools of the software craftsman: TDD, design patterns(command, strategy, observer, etc ), decoupled design, source control, continues integration, paired programming, etc.  and by using any of them you will end up with better software with lower overall costs and yet it feels like it’s a constant battle to get them into our development process.  We need to take a stand, we need to be craftsman and insist on building quality products.