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...


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.

  • 57
    To all: Please don't post "Run away" or similiar answers. It is a valid business concern, because no matter how clean the code is, if the business runs out of money no one gains.
    – Michael K
    Commented Jun 28, 2011 at 18:23
  • 62
    "They never see the code." Yeah, and most people never see the inside of their air conditioner. Fixing a refrigerant leak with duct tape is still unethical.
    – Steve S
    Commented Jun 28, 2011 at 19:38
  • 6
    You would probably see completely different answers depending on what the software you're delivering is being used for. If you're anywhere in the neighborhood of medical or financial data, running away could be valid advice.
    – robots.jpg
    Commented Jun 28, 2011 at 20:10
  • 12
    Don't mind me, I'm just linking to Martin Fowler's take on the subject.
    – user29396
    Commented Jun 28, 2011 at 22:42
  • 6
    I suppose what your boss understood was code over-engineering and not code quality. He's right about the former. You shouldn't think too much of future extensibility and possible changes. But code quality of existing functionality should be strongly present. Commented Jun 29, 2011 at 6:29

25 Answers 25


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.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – yannis
    Commented Jan 19, 2016 at 8:07

Sounds Like My Old Job

(1 Sales Person, 1 Graphics Person, 2 Programmers)

This used to happen all the time at my old job. I agree that sales drives everything. The shop manager (Skill Set: 80% Sales 20% Graphics) was constantly underselling features customers wanted. A 20 hour job would be sold at a 10 hour price because the customer wasn't willing to pay any more or (I tend to think) the sales manager didn't emphasize enough The Value the customer was getting.

The sales manager would often show prospects features and widgets we built for different customers. And of course he would undersell this feature to the new prospect because we didn't really have to re-code the thing... all we had to do was copy and paste the code from a different website and plop it into this site. We had already built it.

After several back and forth yelling sessions of "Why can't you get this done faster... you already did it for customer x." and "It only took 10 hours for customer y how come it's taking 16 hours for customer z".

We asked the sales guy what the goal was? He said to sell as many of these widgets as we can for as cheap a price as we can.

We told him that we are a quality shop and we do quality work. We told him that by lowering the price he was actually diluting the value of our work and in doing so, when the customer comes back to us for new features that had not previously been developed (meaning the option to copy and paste from site x wasn't there) they would push back on pricing and the sales manager would buckle under the pressure.

We decided to price our widgets at a premium price as is. Any modifications would be extra. We convinced management that if given the time to develop these widgets so we could pull them from our "Code Library" instead of from other websites, we could build them in a more generic way so we literally could plop them into an existing site in 2 hours and get paid for 10 hours of time.

He started selling them "as is" with premium charges for modifications and we were able to plop them in and get them working in two hours. We also started adding these widgets to "Our Website" and stopped using other customers websites as sales tools. We would only use other customers websites to show how the widget could be customized "for a small fee" to act like this or that.

In order to prove our concept we (the developers) stayed late after work a few nights to build a generic widget put it into our code library. Life got better. The discussions changed from why is it taking so long to... "Hey, can you resell this widget customer x wants? If so, what features do you want us to add to the basic model to help you sell it."

  • 43
    +2 for winning the battle Commented Jun 28, 2011 at 21:34
  • 4
    Good call. I seem to remember something from Code Complete or Rapid Development or The Mythical Man-Month saying that re-usable components, as a rule of thumb, take about 3 times longer to build than one-offs. So when you re-sell them for the fourth time, you’re into pure profit. I suspect the key to selling this guy on quality was when he asked “It only took 10 hours for customer y how come it's taking 16 hours for customer z?” Quality means re-usability, which means re-sellability, which means that after a few months you can buy a sports car and a set of steak knives with your bonus. Commented Jun 29, 2011 at 10:31
  • @Paul - Yes, the proof was in the pudding. Sales picked up dramatically when these widgets existed on our own site. He could show the "As-Is" model for say $500 and then show of a couple different varieties that our customers had asked for and of course there was a small custome programming fee. Commented Jun 29, 2011 at 14:11
  • @Cape: right, I can imagine it was great having an actual working version there. Promises are one thing, but having something to try is very cool — people like products. Apple Stores seem to work in the same way. Commented Jun 29, 2011 at 14:28
  • 5
    +1 a million times. A salesperson who wants to "sell as many of these widgets as we can for as cheap a price as we can." doesn't understand sales; The goal is always to "maximize the margin", the difference between what it cost you to make (quantity) and how much the customer pays (price) means you really want a few customers who pay a lot. that is a profit. Volume only applies to commodity businesses, and code/creative work ain't a commodity and it never will be. Commented Jul 1, 2011 at 17:54

I have seen companies do this. They end up with angry customers. Customers have a habit to come back and ask for new features as soon as the app starts to make money for them or is integrated in their business flow. You will soon have to tell those customers that you can't add new features to the mess you created, because you can't handle the code base anymore. Or it will take you a lot more time .

Customers (even in a competitive situation to each other) tend to talk. Either directly, by employees switching companies or by random meetings at events typical for their line of business (conferences, exhibitions). You will very soon find it difficult to acquire new customers if your company has a bad reputation.

In addition: Low quality coding works only (if at all) if you limit your company to very small projects. Anything larger or more complex will lose time (and that for money) instantly, even within the first live cycle of the project, simply by spending more time debugging than estimated.

  • 8
    It goes both ways. The company my company replaced spent so much time documenting and designing to the extreme that the customer looked elsewhere. The work the other company did was good, but it was extremely expensive to build and maintain, drowned in violations of YAGNI, and wasn't much better than more agile, less "crafted" stuff. It's a balance. Commented Jun 28, 2011 at 20:59
  • 1
    Companies which sell programming services with high quality code are in minority. So the invisible hand of free market says: crap code is the right way of doing that business.
    – Greg Dan
    Commented Jun 28, 2011 at 21:32
  • 5
    @Greg: I think this is a bit too pessimistic. Though I can only speak for Germany and the Netherlands, I can say that doing quality work has it's place. And the 'free market' (a delusion anyway) is not dominated by price alone. There are many factors and creating bad products will fail more often than not. Commented Jun 28, 2011 at 22:21
  • 1
    Late comment, but "quality" in the eyes of a perfectionist is a very, VERY different beast than "quality" from an actual user perspective. As an end-user, if you spent 10 hours optimizing a once an hour query from 0.1 seconds to 0.01 seconds, you just wasted 10 hours. If you did this for a query that runs 10,000 times a second, it's an actual optimization.
    – Nelson
    Commented Sep 28, 2016 at 3:00

Teach him about technical debt

What you have to do is to make him realize the consequences of the choices that he makes. Quick and dirty can be alright sometimes because you can get things done quicker, but it does have long term consequences.

If for example the project was never intended to have a large code base, quick and dirty might be the perfectly correct way of dealing with that project.

Ward Cunningham came up with the brilliant metaphor, "Technical Debt". Just as you might take a loan in the bank to get something quicker (instead of saving up), you have to pay more in the long term because you have to pay interest. This can be a good thing, if the value of getting your "thing" quicker outweighs the cost of interest.

Quick and dirty solutions are just like loan in the bank. And again, if the value of getting a feature earlier outweighs the cost of cleaning up afterwards, then taking the loan could be the correct approach.

But if you take more and more loans in the bank, then in the end you pay all your income in interest. Just the same with technical debt. If you have made too many quick and dirty solutions you technical debt will be so high, that your progress will come to a grinding halt.

I have seen this happen. In one project I worked on, the technical debt was so severe that we seriously had no progress for 3 months, just trying to fix bugs, which introduced new bugs, etc.

If you can make him thoroughly understand the concept of technical debt, hen he should be able to make the correct decisions (good luck, it's a toughie). Note that the correct solution occasionally also means quick and dirty.

One last thing you might point out is that developers are more productive if they are highly motivated ;)

  • 2
    +1. An excellent metaphor - I'd never heard it put like this before, but it hits the nail on the head.
    – Scott
    Commented Jun 29, 2011 at 14:25
  • I love this metaphor whenever I see it, it applies to so much of what we do in IT. And I agree - sometimes it means that Q&D is the answer just as much as it sometimes means you have to take the time to do things properly. The key is appreciating the risks and advantages of both approaches to make the right choice.
    – Rob Moir
    Commented Jun 30, 2011 at 11:22
  • This is awesome, such a simple way to explain it without having to use too much arguments. Commented Jun 12, 2018 at 19:52

The cost of maintenance is often much higher, and often the majority of the cost, of a piece of software.

If you program quick and dirty, then maintenance is going to be an order of magnitude harder, and cost is too.

If you build all your software quick and dirty, it is going to be crappy and buggy and your clients are going to notice. In the long run, if your products continue to be crappy and buggy, you will loose them. Clients will want to pay your competitor a little more for a good quality product than suffer your bugs.

Does your boss not understand this?

  • 12
    if your company is getting paid to do the maintenance by the hour, the more expensive it is and long it takes is better for your company! His boss does understands this and sees low quality as a positive revenue stream not a negative.
    – user7519
    Commented Jun 28, 2011 at 18:50
  • 10
    @Jarrod Still I think your clients will not be happy with you if you rip them off by making them pay for the bugs you made yourself.
    – Jesper
    Commented Jun 28, 2011 at 20:02
  • @Jesper, my clients never had to deal with that, @Kristof's are apparently fine and happy with doing that, more power to them, they probably don't know any different and given his geographic location his competition is probably worse or non-existent.
    – user7519
    Commented Jun 28, 2011 at 20:22
  • 1
    @Jesper, what you call ripping people off can also be refered to as getting what you paid for. If they are paying for quick and dirty, delivering quick and dirty is not un-ethical, its what they were willing to pay for. By your reasoning it is un-ethical to sell anything low end. There are McDonalds' of software development the same as they are in the restaurant world. The poster says it is hard to get a job doing what he is doing because there are so few, that means there aren't many companies doing what he does locally, which means low competition.
    – user7519
    Commented Jun 28, 2011 at 20:39
  • 4
    @Jarrod - We've had some arguments with customers who wanted extra features ("What? How can this small feature cost me over a third of the price of the entire application?") or bug fixes ("What? I have to pay for your mistakes?"). We've also had customers leave to the competition for this. And I said there aren't a lot if .NET companies around here. There are a lot of PHP companies though. They're competition as well. Commented Jun 29, 2011 at 6:16

In all but the rarest of cases, you cannot convince someone who is insanely short-sighted that longer is almost always better in our profession. Sorry, but that's the truth; short-sighted people will sacrifice everything down the road to reap the benefits now, and almost always suffer in the end.

Sometimes the correct solution is to change positions to a place where people are smart enough to understand the benefits of quality and aren't short-sighted.


Note: this answer takes a business-communication strategy that tries to use reason to make sure everyone is getting what they want. If the problem is simply that doing low-quality engineering is sapping your will to live or that your boss is a slave driver and there appears to be no end in sight, it may in fact be time for a change of scenery.

You are not speaking your boss' language. Part of your job is to give your boss information so he can make decisions, and you need to change your information-giving strategy. You are speaking in engineering-speak, and what he needs to hear about is risk, cost, investment and return. You also need to be a bit defensive and make sure that there is a good record of what you inform him of.

There are two parts to this:

The first is communication of your estimate, and of the idea that it's not a goal or a plan. I could write volumes here, but it would basically be a copy of everything in McConnell's "Software Estimation: Demystifying the Black Art", a book for which you should run, not walk, to your bookstore. Be careful to distinguish between estimates, targets and commitments, and make sure you do a real estimate before committing to anything!

The second is communication of the real risks that your boss would be interested in. Put simply, this means you need to tell your boss that the implementation that could be completed in 1.5 days will fulfill the basic requirements but will significantly increase the risk that future changes and features will require vastly more time than it seems like they need. If he asks why, use the house-building analogy: if your software is a house, every change is a new piece of furniture, and every feature is a new floor. If you don't have a strong foundation and remodel/refurbish a bit every time you do something, eventually you'll be in the situation where the a major remodel will be needed just to support the weight and size of a new window treatment, and the whole house will have to be rebuilt if they want to support four new floors and a deck.

This puts the ball back in your boss' court - you have given him information, and he needs to decide. He'll need to think about whether or not there are going to be any future changes and whether or not he wants to ignore the possibility. From there, if it's decided that fast and low-quality is the way to go, make sure that you (tactfully) shoehorn reminders about that decision into virtually every piece of communication and documentation you can. Send a follow up email that confirms the decision and the risks you communicated, committing it to writing. Make a note about the engineering strategy and the risks in your spec.

When the day comes that the customer wants a pool put in on the 50th floor, and you see that the last 20 floors were built with sticks and sand, make sure that the big fat estimate you produce for it is technically justifiable and get ready to roll out the paper trail of low-bidder invoices to illustrate why it's going to cost so much.

  • I love the "software is a house" analogy; even though the concept of Technical debt should tell a business person that its a bad idea to have too much debt, this example makes it intuitively clear why quick and dirty hacks have such a compounding effect, without requiring any IT knowledge. Commented Jan 10, 2017 at 22:04

If you truly have made all those arguments and he still brushes them away, then it is your duty as a professional to raise this concern to a higher instance. Yes, that means go over his head. The reason for that is simply that your boss is a danger to the company.

My experience with these guys is they will eventually drive your organization into failure or at least mediocrity. Your product will suck and your customers will leave you.

For the record: I am assuming the organizations core business is software development and the product is important and not some throw away thing.

  • 4
    @Martin you advice will just get him fired, it sounds like they do work for hire and not product based sales. Going over his boss's head will be a political disaster and severely compromise his job at best and get him fired at worst.
    – user7519
    Commented Jun 28, 2011 at 20:31
  • 6
    @Jarrod Or get him promoted... Either way, this is a what it means being a professional developer. Believing in your craft and taking a firm stand. Upper management needs to know the truth. Let them decide. That is the right cause of action. Commented Jun 28, 2011 at 20:44
  • @Martin, read his other questions, he will not have any positive affect, doesn't sound like there is an other upper management.
    – user7519
    Commented Jun 28, 2011 at 20:45
  • 4
    @Jarrod: Well, that makes it easier. He should smile and nod while looking for a new job. Lets hope he finds one before his current company fails. Commented Jun 28, 2011 at 20:55
  • 4
    @Kristof then you're screwed. @Martin is correct in everything he says; it's up to professionals to push quality and force management to see it, or else find a place that does value quality and craftsmanship. Commented Jun 29, 2011 at 14:26

Your boss could be right. I can think of scenarios where this type of coding is sufficient. Say you write throw-away scripts for some sort of data analysis or dinky websites where you can pretty much look at a few pages and get an idea of what is going on. These types of things do not need to be overengineered, since it unlikely they will be maintained. If that us what the clients want, then that is what the clients are going to get.

Now it could also very well be that your boss is mistaken, and the clients will not appreciate poorly functioning products. This is most often the case.

It could also be an option to come up with some sort of happy medium. The main thing is that if something is not working, then it needs to change. Clearly your boss is not satisfied with how the development process is affecting the business as is. Time to market is every bit as important as product quality. What you need to do is make the case that your team can produce a quality product in a timeframe that will not destroy the marketability of the product. If engineering principles are used correctly, it should not destroy a teams productivity. If anything, using sound practices should speed up the development process AND increase quality.


Yes, we can hack that together today.

If we do it that way, it's going to have more bugs than average, and will seriously set back future development. Hacking this together is really something we can do once or twice. Think of it as a sky scraper, we might have a nice foundation already, and we have 10 floors that are really nice too, if you want, we can quickly slap together some tents and boxes up onto the 11th floor, maybe even build a 12th floor out of tents and boxes, but you're screwed for going beyond that. We have to move everyone out of those two floors, set them up, re-train everything, and build it all over again just to get the 13th floor.

If we try and build a 13th floor out of boxes and tents, we could collapse three floors at any random time, and it might take us months just to get the jenga blocks and the super-glued duplo in the right spots.

Is this acceptable to you?


W. Edwards Deming's is best known for his work in rebuilding Japanese manufacturing following World War II. Often overlooked is the fact that his work is actually more about management than about manufacturing. In fact, a major section of his book Out of the Crisis is about improving quality in service organizations. His examples of service organizations include software, banking, insurance, and churches.

Deming argues--with a lot of real-world evidence to back it up--that increasing quality increases profit.

You can analyze software development as a business processes. Like manufacturing, it produces intentional, unintentional, direct, and indirect products.

Intentional direct products of manufacturing and programming include faucets and source code. Intentional indirect products include debt and income.

Unintentional products of manufacturing processes include faucets that have manufacturing defects, accidental fires, injuries, high staff turnover, and employee theft. Unintentional products of programming processes include bugs, maintenance difficulties, scalability difficulties, security issues, high staff turnover, and employee theft.

Every one of those "products" is subject to variation, statistical analysis, and process improvement.

In your case, you probably need to enumerate and quantify the unintentional products of your software development and project management processes.

Deming is one of the main reasons Japan is a world power in manufacturing. The Deming Prize is named after him.

  • Programming is not manufacturing. Programming is design. Commented Jun 29, 2011 at 13:41
  • You can do good design in your head. Quality requires both design and execution. (And Deming would probably add "and statistical testing and improvement.") Commented Jun 29, 2011 at 13:57
  • Writing code is design too. The computer does the execution. Commented Jun 29, 2011 at 18:31
  • 1
    The computer executes machine code. The programmer executes a design by reducing ideas to source code. One of the seminal ideas in Deming's work is that statistical analysis applied to quality improvement is effective far beyond manufacturing. (Much of his work in this country was with the US Census Bureau. And an example he cited in the insurance industry characterized one business as having--along with its other more conventional products--accidental fires, the number of which varied exactly like every other measure of quality.) Commented Jun 30, 2011 at 9:23
  • Some programmers are 10x more productive than others, and that difference not reducible by training. These differences in productivity are the antithesis of a manufacturing process. Commented Jul 2, 2011 at 7:06

This may seem like the obvious but I think you need to find a middle road. Don't discount your bosses attitude out of hand. Your view on it is probably as foreign to him as his is to you.

Either extreme is obviously not good for anybody so try and negotiate a middle ground.

  • I probably should have mentioned it, but currently we are on the middle ground. :-) Our code quality is not good. He wants to make it even worse. I mentioned DRY and SOLID. Well, that's something I'm talking about at work because we don't follow those principles. But the boss wants to degrade the quality even further. Commented Jun 28, 2011 at 18:30
  • @Kristof: Well, you've voiced your concerns, but ultimately he's the boss. It sounds like he understands what you are saying, he just doesn't agree that what you are proposing is a good business decision. So... yeah, that's all you can do. Commented Jun 28, 2011 at 19:02
  • 1
    @Kristof: It may be that he is afraid you'll over-engineer in the name of SOLID, which is sort of understandable. You mentioned DRY, but have you explained YAGNI to him? Following YAGNI helps you steer away from over-engineering and complexity. Commented Jun 29, 2011 at 7:28
  • @Martin: Could be, even though I haven't mentioned SOLID to my boss. I've only talked about it with my fellow developers. At this point, we're not doing things SOLID and not very DRY either. It's not like the boss wants a status quo ("don't introduce SOLID"), he wants to degrade the current quality. I can absolutely understand that this makes sense for some small projects here and there. But we're making the switch to product development, and in that regard I can't agree with him. Commented Jun 29, 2011 at 7:43
  • @Kristof: For discussions with non-techies, use technical debt, DRY and YAGNI as arguments. SOLID is too hard for them to grok. Anyway, you might want to update your question with the fact that you are developing products. As it stands now, its not obvious. Commented Jun 29, 2011 at 8:32

I don't think its possible. Different companies have different cultures and if the the culture of your current company (quick and dirty) doesn't suit you then I think you should move on. Some other companies have an opposite view and there you will work with people who think the same as you do.

I don't really want to get into the discussion which kind of culture is better (see the other posts if you are interested), all I am saying that it will be beneficial for your mental health if you work in a company with the same approach.


Ive gone trough all the questions and see that nobody has gone into the perspective of security...

Yes others mentioned debug time, but debugging is in this case only done to the level of 'hey it finally works'

In my projects (small and/or big) I keep a high level of attention to exploits and possible security holes.

Taking these into account and testing them does take a considerable amount of time, but atleast this way they won't be accusing me for not doing the best I could when something bad does happen.

I bet that when you're going quick and dirty forget to sanitize some variables, forget to do some checks in functions and thereby make your project a nice point to start at for hackers.

When my boss asks why something took me so long, I show him all the security and function checks I've build in to prevent things like injection, inclusion, infinite loops and even the security measures for when something does get hacked it does minimal damage


I am somehow in similar situation as you. I work for a service company, so I write custom application for different clients. People who is in charge of delivering the application (like project managers, project executives etc.) really don't care about the code quality (although they say they do), all they care about is delivering stuff on time so they can maximize the profit. I constantly get asked to write features within short amount of time.

A technique I used to maintain code quality while meeting the deadline is continuous refactoring. If I'm asked to write feature A in 1 day, which will actually take 3 to 5 days to write with high quality, I will just do the quick and dirty way and deliver. But while doing the quick and dirty way I keep notes on the area that can/should be improved. Then later in the development cycle I will just find pieces of time fragments here and there to refactor my code in feature A.

In the beginning, it was an painful experience refactoring my quick and dirty code; I remember few instances where I almost completely rewrite a feature during refactoring. But as I do more and more refactoring, my quick and dirty code started to become not as dirty. I started to develop better natural sense of modular design, so that codes I write become more and more modular even if I'm in the quick and dirty mode.

It's not wrong to think that code quality doesn't matter, because to a lot of people it actually doesn't matter. Like do you really care about the design quality of the circuit inside your SONY TV as long as it displays nice HD picture and works fine for 5~10 years?

As a developer though, you should really care about code quality because you know the benefit of it. Your boss is unlikely going to change his mind about code quality unless he experience some crisises where code quality saves his day or when he personally see the correlation between profit and code quality.

Just because of your boss' lack of knowledge in code quality, doesn't mean you should compromise code quality (however, it is still a good idea to keep the communication channel open with your boss about the code quality). Strive to find the balance point between code quality and development schedule. You can't write good quality code for current given schedule doesn't mean you can't improve the quality in the future schedules right?


Doing things quick and dirty can slow you down even before lunch. Very often it will start to hurt even before you are feature complete enough to try and get it accepted by a client.

Perhaps you can try the technical debt metaphor, the burden of interest payments will be larger then the income after some point.

Steering towards a rewrite is also an opportunity for your customers to try out a different development company (if we are to start from scratch they might as well).

If you have no alternative employers in your area there might be more then plenty of customers to wear out also. So basically your boss can keep up doing what he's doing, no competition who does any better. Perhaps start your own business? ;-)

Alternatively you could just tell him you always do things 'quick and dirty' and just do your own thing.

  • I think this is an under-appreciated perspective. In many instances, I've found going quick-and-dirty starts hurting my ability to get things done within hours, not weeks or months. Commented Jun 18, 2013 at 1:29

Throw math at him. Unfortunately I don't have the books on-hand to provide citations (hopefully someone can help me out), but one or both of The Pragmatic Programmer and Code Complete 2 have a section referencing studies that show the cost impact of doing things the quick 'n 'dirty way, versus taking time to fix it later. Other posters have provided plenty of bullet point arguments, but depending on your boss's demeanor, he may respond much better to support from existing studies. He may think you're just blustering to buffer your time and ease your own workload. Showing him that it's an industry-accepted fact, as opposed to just your opinion, might be the ticket.

  • 2
    If the consultants are being paid by the hour, taking longer means more profit. And the "dirty" code is more likely to have a bunch of features semi-working in order to be able to demonstrate progress and keep the contract going. Unfortunate facts of life.
    – Ben Voigt
    Commented Jun 29, 2011 at 0:30

I have a strong feeling there is nothing you can say in this case. But a few points I'd bring up:

Fixing Issues Takes Longer

When you copy and paste code all of the place, when you find a bug in that code it will take longer to fix, and it will take longer to test. Thus you will be wasting extra hours in the support phase (as I'm guessing you don't have an integrated testing phase with a 'get it out the door' mentality).

Adding a New Feature Takes Longer

Adding a new feature in spaghetti code takes so much longer. And because it's a copy and paste mess, you have to tweak code in many places. This in turn will create bugs, or unexpected functionality in various places. Thus, you'll have to waste extra hours in the support phase.

Skinning UI Elements and Terminology for New Clients Takes Longer

Company I'm working at right now their web client started off being a copy and paste mess of spaghetti code. Before I started it took 2 weeks to skin the web client for a new customer.

After more than a few long evenings, it now takes an afternoon. I'm still working and tweaking it so that it will take less time.

If your boss wants to make a product that is easy to sell do different customers, he needs to invest the time to make sure that you won't waste time skinning your product when you could be selling them new features.

It's going to be hard, but you need to make your boss understand that unless you spend sometime now to make sure it's done right, you will waste many more hours in the future on bugs, and it will actually take you longer to get the product ready for a new client in the future.

All he cares about is the bottom line, so you need to make him understand that coding this way won't help it and will only hinder it.

  • you don't take into account all those wasted hours they are billing the customer for and making a profit, none of these arguments will hold water in this situation since none of them are negatively affecting the companies ability to turn a profit.
    – user7519
    Commented Jun 28, 2011 at 18:57
  • @Jarrod Roberson - Maybe it wouldn't affect them turning a profit in the short term, but in the long term it would help them turn a bigger profit. And will your customer be your customer for long if you have to take a week to fix a bug on a feature that took a day to give them? Shot term gain at the expense of long term profitability doesn't seem like a good business model to me.
    – Tyanna
    Commented Jun 28, 2011 at 19:15
  • doesn't sound like they have much competition in his geographical area since his job is scarce there, they are probably pretty well ensconced as the only vendor that does what they do. It also sounds like they only do work for hire and not products they sell, completely different businesses.
    – user7519
    Commented Jun 28, 2011 at 20:24

Best possible answer would be from Agile approach:

release early, release often

Release early is good for your company because you start getting paid early. The first release point is when your product has enough functionality so it can be used at least in some aspect. So it adds client company's value. That's why it's smart to develop module by module.

Release often is good for your client because they'll sooner get what they need. I intentionally didn't write want, because the end result frequently differs from the idea at start.

If nothing else this will satisfy your clients more since they'll feel more involved and you will be iterating your product step by step.


One thing I found out was that a clean codebase can support a skin of cruft without too much trouble. If you have a core CMS that you customize for different people, any issues in the core will haunt you. But a poorly tested, poorly done customer-specific plugin can get by without much trouble.

In your case, it sounds like you haven't built up the clean core, so you're pretty screwed. Still, you should prefer asking for time to improve your core codebase, which should benefit your existing customers and speed up future development.


I want to cut it short.

  • If the code is gonna maintained for long time, code quality is an issues.
  • For prototyping code, it's not really a big deal. Usually people throw away such code.
  • The quality of code written by a programmer is achieved through practice. As the way we get experience, we will achieve good speed Vs. Quality ratio. I have seen programmers who used to ask, "Give me 3 days to update with coding standard". This is a complete shit. Why they're taking care while writing the code itself? Once the test is done, and going for standard updates could lead to problems.
  • Even we don't officially design something, we will have some kind of design in mind before writing the code. In these situations, the quality rely on developer thoughts.
  • Managers are notorious about schedules, effort and budget. If you can do something in a given boundary, agree it. Otherwise tell him what you can do within the given period. Or give suggestions about the people who might be able to contribute well for the particular problem

Tell him that he can save money. Roger Pressman wrote that you spends 20% of your money building the software and 80% maintaining it.

If you need to build quickly to don't lose a contract, do it, but in a alternative branch. After that, do it again in the right way.


How to get the best of both worlds? Use software factories. Spend your brain power on creating tools that can do the stuff that can be repeated. For example take a look at Ruby on Rails or if you're a .NET person, look at ASP.NET MVC combined with a nuget package called MVCScaffolding. I'm currently digging into this tool and customizing it to generate what I need for my workflow. Generating a simple, database-backed CRUD website is as easy Scaffold controller . Now I can spend my time customizing the UI and refining the business logic that drives the app.

As I mentioned, you can customize the tool (for example, I changed the default controller template to use my in-house IRepository/IUnitOfWork utilities allowing me to easily switch between EF and InMemory datastores for testing). For the most part, the majority of my development is spent refining the object model to support the business usage scenarios.


LIE: When your boss asks how fast for "quick and dirty" - tell him "that was the quick and dirty estimate".

Many of the answers on this thread are based on reasoning. The ultimate flaw in this approach is that you are talking to a business man.

The problem is, your boss - as with most business leaders in SME environments - is not really concerned with the long term view. No matter how much reasoning you bring to bear, if you even suggest there is a quicker option, he will take that option 99% of the time. Bosses like to pick arbitrary figures out of the air that support the sales pitch, and then the dev teams soak up the damage in overtime and low pay. Clients have unreasonable expectations borne of ignorance, and bad bosses are all too willing to accommodate them.

Who's making the profit? What is this process doing for your long term career? It devalues the work and ultimately the worth of your skill. Even if you're a short term contractor, think of the long term effect on the industry of undercutting the cost for reasonable work.

By all means, cut your garment according to your cloth - but "quick and dirty" is not an option. If the client asks for a feature, that feature takes a base level of time to complete to a reasonable standard. Do not provide times for anything less than a reasonable implementation.

  • 4
    I would downvote this if I could. Moral convictions aside, misleading and undermining your boss probably puts your long term career at greater risk than following through on his bone-headed plan.
    – Steve S
    Commented Jun 30, 2011 at 14:02
  • 1
    The reason the OP is being put in this position is because the boss is misleading the client to expect something that can't be delivered in the time frame. The net result is a culture where code is cheap, we all work over time and hate our jobs - which to me is of far greater consequence in my long term career.
    – sunwukung
    Commented Jun 30, 2011 at 14:24

I would introduce your boss to LulzSec. They might beg to differ that quality of code in web apps doesn't matter...

Not the answer you're looking for? Browse other questions tagged or ask your own question.