I am working on a new project and the code is shared and written by at least ten software developers. There are some modules which are readable and there are some parts which are totally spaghetti code.

I tried to bring this point up and mentioned this to our client and architect and also proposed unit testing. Our client doesn't endorse these things and is only interested in feature development and doesn't care about quality and regression.

Our architect and I agree that unit testing will help us keep the regression at bay before introducing newer features.

How do I educate our client so that the project doesn't implode soon, as there are many people working on it and it’s better late than never to incorporate some sort of process that will yield better quality?

  • 7
    Are you contracting your effort to your client, meaning they pay you by the hour to do work they tell you? Or are they paying you to provide a specific software deliverable? Jun 2, 2021 at 14:03
  • 2
    @JoeStrazzere Unless you are working under a maintenance contract I would normally see bug fixes as falling under a warranty aspect of a project, and not charging for them (assuming that it is an actual bug and not a brain dead requirement). On the other hand Scope changes are open season for $$$
    – Peter M
    Jun 2, 2021 at 17:03
  • 9
    Anything you show them on an estimate will be seen as a line item that can be eliminated. Therefore, don't show anything that can't be eliminated. Jun 2, 2021 at 21:31
  • 12
    I've never met a client who truly didn't care about quality, regardless of what they said. If you tried getting them to pay for trash with the disclaimer "but you said you didn't care about quality", that's not going to fly. What will happen then is there will be a debate about what was said or (mis)understood. Jun 2, 2021 at 23:54
  • 2
    If this is an external client, are you basically saying "what you bought so far from us is crap but I the new guy will fix it"? I'd be out the door faster than you can finish that sentence.
    – DonQuiKong
    Jun 3, 2021 at 9:24

6 Answers 6


You're going into too much detail with your client.

They presumably came to you (well, your team or your company) because you know more about software development than them. It sounds like you are now trying to educate them about software engineering to help them understand the benefits of unit testing. You should instead just include the time to create appropriate unit tests in your estimates for new features.

If you get questioned about why estimates seem higher than before (or if you'd prefer to be more transparent up front), explain that the higher investment up front will result in lower maintenance costs and so faster access to more features in future.

This opens the possibility for your client to express a preference for lower cost features now with the risk of high maintenance costs in future. If the client is internal, escalate the issue to ensure the business is bought into this approach. If the client is external, they are perfectly entitled to spend their money in this way. So long as you don't mind bug fixing, your future employment is secure.

Don't worry about proposals for refactoring any existing spaghetti code for now. If your client sees the benefits from testing new features, they'll be more likely to support investing in the existing codebase later. If you end up not testing new features, there's no way you'll get agreement to retrofit tests (see previous comment about future maintenance payments in that case).

  • 76
    Couldn't have said it better myself. - As a Software Engineer you have to learn how to speak to clients without going into the technical details. I'd never mention the words "unit testing" to a client, unless they specifically ask about it.
    – flexi
    Jun 2, 2021 at 12:40
  • 37
    "You're going into too much detail with your client." precisely correct. Just do it properly and say nothing.
    – Fattie
    Jun 2, 2021 at 12:41
  • 37
    My last company had an issue where we gave a granular breakdown of a feature including documentation and testing time. Clients would always come back and demand we skip them to save cost... This lead to many problems. - The second we started giving a single price per feature, clients didn't say anything and just accepted the work.
    – flexi
    Jun 2, 2021 at 12:44
  • 9
    This answer is absolutely correct. (The client also doesn't pay for bugs, so stop delivering them bugs!) In addition I would also say that giving them a fine grained view about the nitty gritty also limits the scope of potential process changes. Maybe Unit Testing isn't found to be useful, but some methodology like End-To-End testing would be more beneficial. But to do that you have to go back to the client and renegotiate. Far better to hide that from them. Jun 2, 2021 at 16:27
  • 44
    Exactly! For surgery, the surgeon doesn't ask his patient for permission to wash and scrub his hands for 5 minutes. And at a restaurant, the chef doesn't ask his customers if they will allow him to sharpen his knives, clean his kitchen, organize his pantry/fridge, or warm up the grill before he cooks a meal. He just does those things simply because experience has taught him that kind of prep work is important. If the customer thinks this is taking too much time, he's free to go elsewhere or hire his nephew to do the task instead. If your client is being unreasonable, you need to fire them. Jun 2, 2021 at 19:13

When a professional gives someone an initial estimate, it should be for doing the job “right”. For software that isn’t a one-off, that usually includes investigation/design time, unit tests, integration tests, QA time, and all of the other necessary parts of developing good quality code. If the initial estimate is too expensive or will take too long, then you negotiate which features will be reduced in scope or dropped, or a shortened QA cycle with increased risk.

Dropping unit tests would not be something I would be willing to put on the table as I consider them part of normal development. I might offer to create a “quick and dirty” prototype a feature if we agree we throw away the prototype and do it properly if the client does want that feature.

I don’t hire a master plumber, then second guess the necessity of each of the steps they do to get the job done. Why is your client that deeply involved in your development? When you create a new feature you estimate the time to do it right, including unit tests for the new feature and making any legacy code you’re touching more robust.

It’s unrealistic to expect a client to want to pay for your team to clean up your code to make it easier for the team to work with because the team didn't take the time do a good job the first time around.

The team needs to start factoring unit testing and fixing smelly code into their estimates for everything going forward, instead of trying to get the client to pay to bring old code up to the quality they should have received when they paid for it to be written.

  • The other thing is that if you build something the wrong way and it has financial impact on the client (say, you create a payment gateway interface that pulled money from thousands of the wrong accounts and sent it on to thousands other wrong accounts), the client is going to point the finger at you & you're liable for doing it wrong. You have to protect yourself.
    – HenryM
    Jun 4, 2021 at 14:51

How do I motivate our client who is averse to unit testing and only wants features and bug fixes?

I guess you say, "it won't cost more money or take more time." But is that true? Sometimes it is. Sometimes it isn't.

The client isn't going to listen to you because you're not high up in the hierarchy. The architect already tried and failed to convince them so they have no reason to listen to you. For all you know, the architect even told the client that testing wasn't required.

Sometimes a client needs to get to market asap in order to raise more money. They don't care about the long term maintenance cost. Of course, if you know it's absolutely critical to test (financial apps, medical scanners, vehicle controls and such) then you either do it right or get a new job somewhere else and/or report it to the authorities. If you're building a website for muffin shops or something don't sweat it. It's the client's choice how they spend their money even if it's foolish from a technical standpoint.


You don't. You do what the client asks. You educate the client that if you are not given a timeline which allows for enough leeway to add these robustness features then it the software will not be fully tested and may have bugs and other issues, and if they want a robust piece of software then they have to give you a timeline which allows you to build a robust piece of software. If the client doesn't care if their server crashes, then you build what you can and let the server crash.

CAVEAT: I'm assuming you are a direct contractor of the "client". If you are an employee of the client, then you should discuss with your manager about the software development practices and ensure you're on the same page, because whatever you build will look bad on your manager if it's bad. If you are an employee of a consulting company who has this client, you should alert your manager at the consulting company that the client has explicitly asked for no testing to be implemented (in writing if possible) so that if the shit hits the fan (which it inevitably will), your company's ass is covered in that the client can't say they weren't warned or didn't know.

  • Well, it's not just that the software will be buggy if there are no unit tests. It's that fixing those bugs later on will be (potentially, much) more expensive than paying for the tests right now – even ignoring the cost of the bugs themselves, if they turn up in production. Jun 4, 2021 at 23:25
  • 1
    True. But that's not OP's problem. That's the client's problem. If the client would rather pay more later to debug OP's buggy code because they didn't give OP the tools he needs to write proper code in the first place, that's the client's problem. OP is giving them fair warning that the product may not be perfect when it's delivered, and that's where OP's responsibility ends; if the client accepts that risk then it's the client's responsibility to clean up the mess, or else to give OP the tools he needs to prevent that situation.
    – Ertai87
    Jun 5, 2021 at 2:25
  • Agreed, though the fair warning should be stronger than just “the product may not be perfect when it's delivered”. (Even with unit testing, the product is sure to be not perfect...) Jun 5, 2021 at 10:50

In many shops, deadlines are more important than resolving all the issues. I was at a shop where, if a deadline was missed, the company could lose 1 million USD. The company said that they could issue updates later and the updates could contain the fixes.

In project management, you have to weigh your priorities. For example, one project I was working on was falling behind schedule, so they reduced many of the requirements. Similarly, issues should be ranked, so that the lowest priority issues are removed as necessary to achieve the deadline.

One of the requirements of the developer is provide a good estimate of the work to the project manager. The developer must also report any deviations that they see (coming up or immediate). This allows the stakeholders to review the schedule and make changes accordingly. The earlier the reporting, the better rescheduling choices.


Obviously, the later a bug, problem, difficulty, or misfeature is discovered, the more costly it is to fix. Unit testing is critical so that the units can be built on and put together and work. This is only common sense, with mechanical devices or business plans, just as it is with programs and system designs, yet it is often very difficult to get people outside the craft to understand it. Maybe some education with really simple physical analogies will help.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .