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:


Smallish websites built with our own CMS or e-commerce framework (65%)
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.

Sorry to say this but,
You aren't going to want to hear this, but he is not completely wrong.

If you are doing work for hire for external companies as a consultant,
and they are willing to accept the most slapped together thing you can
do and don't complain, and are willing to come back over and over
again for you to do more work, your boss is 100% correct when it comes to maximizing profits for your company.

Then there is YAGNI: if the projects are one off projects that won't cost you anything to maintain or re-write and all that time in maintenance and re-writing is billable, doing it right the first time is actually costing you even more money. Then, your boss is 100% correct again.
If your clients are not complaining about costs and lack of quality, then quality is not at issue to make your customers happy. Sounds like the customers are happy with crap so selling them more crap isn't a hard business decision.
Anything you do above and beyond what the customer is happy with is wasted effort on every ones parts: they won't appreciate it. Your boss is 100% correct again.
Remember quality is in the eye of the beholder. If it meets the customers' needs they don't care about the duct tape and coat hangers that are making it work.
What you value greatly has little or no direct value to your customers since they don't care how the software does what it does, just that it does what they want mostly.
Every piece of software eventually degenerates from entropy to a Big Ball of Mud. GUI applications, especially ones for Windows written in some flavor of VB entropy faster because of the culture of the tool set.
If it makes you feel any better, you are just starting off a little closer to maximum entropy than other people.
Personally I would never set a precedent with such low quality deliverables, but then again I would not go for the race to the bottom level of customers your company is apparently trying to cater to.
Your management has decided these are the customers they want to have and there is no need to try to up sell the customer on more expensive higher quality software if they are fine with the way things are.
You aren't going to get management to change, only your customers will do that. You can get better customers, or get a better job.
