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

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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 ;)

Answer 5

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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?

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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