How to convince my boss that quality is a good thing to have in code? [duplicate]

Question

This question already has an answer here:

• How can I convince management to deal with technical debt? 17 answers

My boss came to me today to ask me if we could implement a certain feature in 1.5 days. I had a look at it and told him that 2 to 3 days would be more realistic. He then asked me: "And what if we do it quick and dirty?" I asked him to explain what he meant with "quick and dirty".

It turns out, he wants us to write code as quickly as humanly possible by (for example) copying bits and pieces from other projects, putting all code in the code-behind of the WebForms pages, stop caring about DRY and SOLID and assuming that the code and functionalities will never ever have to be modified or changed. What's even worse, he doesn't want us do it for just this one feature, but for all the code we write.

We can make more profit when we do things quick and dirty. Clients don't want to pay for you taking into account that something might change in the future. The profits for us are in delivering code as quick as possible. As long as the application does what it needs to do, the quality of the code doesn't matter. They never see the code.

I have tried to convince him that this is a bad way to think as the manager of a software company, but he just wouldn't listen to my arguments:

• Developer motivation: I explained that it is hard to keep developers motivated when they are constantly under pressure of unrealistic deadlines and budget to write sloppy code very quickly.
• Readability: When a project gets passed on to another developer, cleaner and better structured code will be easier to read and understand.
• Maintainability: It is easier, safer and less time consuming to adapt, extend or change well written code.
• Testability: It is usually easier to test and find bugs in clean code.

My co-workers are as baffled as I am by my boss' standpoint, but we can't seem to get to him. He keeps on saying that by making things more quickly, we can sell more projects, ask a lower price for them while still making a bigger profit. And in the end these projects pay the developer's salaries.

What more can I say to make him see he is wrong? I want to buy him copies of Peopleware and The Mythical Man-Month, but I have a feeling they won't change his mind either.

A lot of you will probably say something like "Run! Get out of there now!" or "I'd quit!", but that's not really an option since .NET web development jobs are rather rare in the region where I live...

---

Update

Wow, I hadn't expected to get so many answers. Thank you all for your contributions and your opinions!

As quite a few of the answers and comments point out, the type of company and the type of projects play a big role in this topic. I have explained a few things here there in comments on some answers, but it's probably better to add it here as well.

The company I work for is rather small. We have 4 developers, 1 designer, 1 boss and 1 jack-of-all-non-technical-trades (the boss' wife). The projects we do can be divided into two categories:

1. Smallish websites built with our own CMS or e-commerce framework (65%)
2. Middle-sized web applications (35%)

So while a lot of our projects are rather small, they are built on top of the same system. This system is about 4 years old and the code base is below par to say the least. It always is a dread to add new functionalities or modify standard functionalities for specific customers.

One of the goals set by the boss is to start moving our focus to product development. So that means we'll be developing bigger applications that will serve as the base for other projects or are something SaaS-like.

I totally agree that doing things quick and dirty can be the best solutions for certain projects. But when you are extending an existing CMS that will be used by all sites you will develop in the next few years or building a SaaS product from scratch, there are better approaches I think.