A client has asked me to do a redesign of their website, an ASP.NET Webforms application that was developed by another consultant. It seemed like a relatively straightforward job, but after looking at the code, it's clear that's not the case.

This application was not written well. At all. It is extremely vulnerable to SQL injection attacks, business logic is spread throughout the entire application, there is a lot of duplication, and dead end code that does nothing. On top of that, it keeps throwing exceptions that are being smothered, so the site appears to run smoothly.

My job is to simply update the HTML and CSS, but much of the HTML is being generated in business logic and would be a nightmare to sort out. My estimate on the redesign is longer than the client was aiming for. They are asking why so long.

How can I explain to my client just how bad this code is? In their mind, the application is running great and the redesign should be a quick one-off. It's my word against the previous consultant. How can I give simple, concrete examples that a non-technical client will understand?

Walk-throughs will work

Non-techies aren't idiots (for the most part). They can understand a technical argument if you keep it high-level enough. Pick a task you thought should be simple, and walk them through why it's not.

For example: "I expected this change to be one word in one file. The most likely place to change it seemed to be here but when I changed it there, it only worked in one place, and it broke these 7 other places. When I fixed one, it broke two more places, causing a domino effect, so a change I thought should have taken 10 minutes ended up taking 2 hours. That's just one example. There are a lot more unexpected 2 hour tasks in there."

Put the fear of god in them

Code structure, style, technical debt are things—at least initially, until the client trusts you—you're going to need to live with.

Security vulnerabilities are another matter.

Personally, I would do an estimate based on the work required using the existing structure and style while making it clear that there are significant issues with the codebase. I'd raise the security implications separately: do a demonstration of a hack on the database to drive the point home during a meeting.

I had great joy doing this with a previous client with a loyalty gift card system when I put ¬£5000 on "my" card and then had him check the card on his till.

Philip comments:
+1 demo just how bad the SQL injection attack could be. Do it in front of them. If possible, video record their reactions.

Detail everything

Wonko the Sane answers (17 votes):
I would fully document everything that you feel should be redesigned and why (what happens if they don't make the change), and an estimate on fixing the issue. I would be particularly meticulous with anything you perceive as a security risk.

I would do this before touching any code, and make sure that your client has a copy of this report, preferably with some kind of timestamp. It may take some time, but it will also cover you if one of these security risks ever comes to fruition. Even better if you can get something signed that says they received the document.

Sure, you can point to source control of the original code you inherited if it ever does happen, but it will be much easier to point to this document and say, in a more professional manner, "See? I told you so."

This document can be the launching point for further discussions, and it may even be used by your client to get the "right people" to give them permission to make some or all of the changes.

That being said, once the client undestands the risks, grin and bear it if they say do the work anyway, or walk away.

Real-world examples

Remember that the client is coming to you for help maintaining their application. It is your job as a professional to point out any issues you find with this application. The client likely has no idea these issues exist and they should be made aware of them. Explain these issues in a manner that they can understand and let them decide how they want to proceed.

Use real world examples to illustrate these issues, such as a car breaking down or a washing machine needing repair. The point is to use examples they are already familiar with. For explaining SQL injection, I would simply demonstrate what that is and why it's an issue.

In the end you want to convey that you care about the success of the application you are being asked to work on.

Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.

56 Reader Comments

How can you show a client that their *anything* sucks? I've had clients proposing and *insisting upon* all manner of mean-mannered and ugly and disfunctional features for their websites. Demonstration, even with customer testing, sometimes just isn't enough. The question always arises (for me) as to whether "The customer is always right" or it's worth my while and frustration avoidance simply to drop the client.

I'd absolutely demo the SQL injection vulnerability with the most dramatic outcome for them and document it with them in writing. I wouldn't go as far as to do a security audit of the whole app unless you are getting paid for it.

If it is for an internal website they might not think the risk is worth the effort. In that case, if you are still on board, I'd make sure I had it in writing from them that they are aware of the possible vulnerabilities and that fixing them is out of the scope of the project.

simple. Make an info-graphic displaying all of the problems with their code. Bugs, comments, memory leaks. All the nasty stuff. And I agree with @bsharp, a very explicit demonstration of the vulnerabilities should help cement it. It's interesting how exploring their exposure to vulnerabilities will make that total rewrite seem cheap.

I second demoing the sql injection. Let them watch you fire up Firefox and install a free injection plug in and exploit the vuln in front if them so they see how easy anyone could do it. If that doesn't explain it to them, I don't know what will.

I have found actually explaining the process to them works wonders. Don't be afraid to show your work and what you do. Grab an extra chair, pull them close to you and run them thru their system explaining in lay terms what is that you need to do to acomplish their requests. No amount of slideshows or documentation will ever compare to them seeing with their own eyes.

One little secret of ours is that "anything can be done", the real question is if we want to do it and they want to pay for it . Once they see why it takes so much money/time, they will understand.

How can you show a client that their *anything* sucks? I've had clients proposing and *insisting upon* all manner of mean-mannered and ugly and disfunctional features for their websites. Demonstration, even with customer testing, sometimes just isn't enough. The question always arises (for me) as to whether "The customer is always right" or it's worth my while and frustration avoidance simply to drop the client.

That question is easy to answer. It all comes down to how much you value your skills and time, versus how badly you need the money, with modifiers for the client's attitude or connections. (You might take an otherwise unprofitable client because they're cool or have connections.) Every independent contractor eventually figures out their values; if a client doesn't measure up, you just let them know that what they're requesting will take far too much time that you need for other projects, and that you'll have to bill them an exorbitant hourly rate instead of a flat price if they expect you to continue. If they demand to know why, then you honestly state that it was a predecessor who may have been inexperienced and unskilled, or that while what they want sounds simple, it requires changes in every part of the application and some of it is already fragile enough.

If that's not enough, then unless you desperately need the money or the rep, you're free to just walk away from unreasonable people. As ugly and macho as it sounds, you have to approach negotiations and meetings with that attitude to garner respect from a large subset of small business owners, in my experience.

Showing some simple SQL injection might be helpful. If you're in the US, do not under any circumstances break into the system in a way that might cause real money damages. That's a quick route from being a consultant to a jail visit. If you're not a security consultant with a large legal department writing contracts to prevent this possibility, you'll be branded a computer terrorist in no time if you wander down that path.

If you find such a break-in is possible, do not test it. Just document that it might be possible, to CYA, and get out of there. I wouldn't touch a project like this unless I'm being paid so much that I can hire the right legal help to limit my liability in this situation.

Call the client in for a meeting, tell them you originally assumed the previous developer's work was of a reasonable standard and it's not. I wouldn't go into much detail, just say it's full of security vulnerabilities and hidden bugs, and that they would need to be fixed before you could even start the work you originally promised.

Tell them you simply cannot accept the job anymore and appologise for your mistake (don't even contemplate changes someone else's work without seeing it first).

You could offer them a new quote but they might not like you much anymore. If it's as bad as you say, I would insist on building a new website from scratch, or not doing any work at all.

If the client is an asshole, they might insist on the quote you gave them. Maybe it's a good idea to talk to a lawyer at that point, because anything you do could land you in legal trouble.

Showing some simple SQL injection might be helpful. If you're in the US, do not under any circumstances break into the system in a way that might cause real money damages. That's a quick route from being a consultant to a jail visit. If you're not a security consultant with a large legal department writing contracts to prevent this possibility, you'll be branded a computer terrorist in no time if you wander down that path.

The Computer Fraud and Abuse Act in the USA (and probably similar laws in many other countries) is in such a terrible state that I would not even go near the SQL injections.

Jail really is a possibility even if all you do is demonstrate that the issue exists. Do not take the risk, do not waste your time. There are companies that focus on security consulting and they usually don't do anything else. Simply tell the client the problems appear to exist without verifying that they do.

We have a potential client that is running a Non-PCI compliant POS system. We've shown them their own card in the clear in a meeting.

We loaded up a computer with their vendor of choice with a keyboard logger. Had the CEO swipe his personal credit card. Did the same with our system and showed them the card number in the clear with the other vendors solution (the other vendor is adamant they are PCI compliant still).

Now this CEO is a bit of a dick wad so we won't get his business but when I hear about this popular chain of remanufactured printer toner and ink cartridges gets hacked one of my first calls will be to him: Hey, I heard you got hacked...

Gerald Weinberg's Secrets of Consulting says, "tell them to do something different." If they were happy with the previous consultant, they wouldn't have come to you in the first place.

You don't need to, and shouldn't, bad mouth the previous consultant. They already know that or they wouldn't have come to you. Tell how you can help, not what someone else did wrong.

Quote a reasonable (for you) hourly rate and explain why you can't give them a fixed price. You will have to come up with an estimate. Be clear that it's an estimate, give them a range, not a number, and set the upper end high enough to be confident you can do it in less time. If that scares them away, consider that you've been saved!

Don't even think about an SQL injection demo against their application.

I've decided that we are just honest both in tone a price. "Look this change should take about 5 minutes on a site that is properly coded, but because of some issues on your site, it's going to take 2 hours." Give specifics if they ask, but most of the time, they'll either not hire us, or ask for a bid on doing it right.

We don't get a lot of business with this method, but we get better clients. When we first started offering programming, we took a bunch of jobs that sucked, and we did them on the hope that we would be hired for a redesign. Most of the time it didn't work out that way, and even if we did get hired, we were already so much in the hole, that it was hard re-cooping it on the redesign. So we gave up the crap work.

Jail really is a possibility even if all you do is demonstrate that the issue exists. Do not take the risk, do not waste your time. There are companies that focus on security consulting and they usually don't do anything else. Simply tell the client the problems appear to exist without verifying that they do.

Even demonstrating it on a local copy of the site that you own and operate? I sure as heck wouldn't do it to their live site, that's just rude even if it's a minor thing you're doing.

There are two maxims that every technologist should keep in mind when dealing with management:

1) It's not always enough to be right.2) Nobody likes the guy who says "I told you so".

So before getting all self-righteous and launching into an elaborate riff on the atrocities of their codebase, remember that any other consultant would face the same challenges. It doesn't matter that a task *should* take 10 minutes if it actually takes 2 hours. If you're the right person for the job, than it would take any other consultant at least 2 hours to complete.

Either they're going to pay you more than they expected to refactor their code, or they are going to pay somebody else more than they expected to refactor their code. Those are the options left to them by the original developers. That's all they need to understand about their situation. They need to know that it's not going to be cheap, and it's not going to be any cheaper if they decide to hire somebody else.

The problem is that you are looking at a software problem from a strategic level, while they are likely looking at a business problem from a tactical level.

Even if you are able to show them that spending more money now on a rewrite will cost them less in the long run, they may well prefer to continue on the path they are on, spending less money now, and more money in the long run.

On a business level, you have to accept that they know their own business interests better than you do.

Now, you might not want to work on a crappy codebase. That's up to you.

I would refuse a fixed rate contract under these circumstances - you don't know the codebase well enough to be able to estimate your time budget accurately.

Don't spend too much time trying to convince them their code sucks. Explain it to them, sure, and if they say "Well, we don't believe you", then drop them as a client.

You aren't there to explain how to write good code, and why it matters. You are there to WRITE the good code. If they don't want to pay for your expertise, screw them.

Life is too short to deal with cheapskate business owners.

This is a little too binary IMO. It depends on how much you need the business. If you don't need a new client, and you are rolling in dough, its easy to blow someone off if they don't want to listen to your recommendations. If you really need the client, on the other hand, you are going to want to make an effort to retain their business.

My take? The security issues are what's important, but the rest of your worries basically aren't - and I've been in your position more times than I care to shake a stick at.

Does the site do what they want it to do? Then it's working, regardless of the fact that it looks like a pile of vomit under the hood - having business logic all over the place is a code design consideration, as is clearing up dead code or lack of code reuse. Are the smothered exceptions important, are they actually stopping functionality from working, or are they superfluous? If functionality is silently failing, wouldn't someone have noticed by now and logged it as a bug?

My approach would be to go back to the client and tell them that due to the condition of the codebase, there will be an additional cost if they want to go ahead with the changes. Make sure you document why that additional cost has arisen in any invoices sent over.

Clients don't care what the quality of the code is, so long as the end product works as they want it to - code quality is a "well, that's nice, does it make the website any better fit now?" thing.

Put the "fear of god" in them? Seriously? If you walked into a bank and saw a gaping security hole that let you enter the vault - would you demonstrate it by entering the vault? If so I hope you enjoy the trip to jail because breaking into things is illegal even if intended to help.

Maybe they're aware of the security vulns and don't care.Maybe they xcan't afford to fix them. I'd let them know about the security vulns but not put much effort in finding them since that isn't what they're paying you to do.

The world is awash in security vulns. Not everyone is willing to fork over the dough to put concrete rebar everywhere just because you think they should.

I'd toss that attitude up to arrogance but honestly I think it's more a combination of social ineptitude and an inability to take another peraons's perspective.

Put the "fear of god" in them? Seriously? If you walked into a bank and saw a gaping security hole that let you enter the vault - would you demonstrate it by entering the vault? If so I hope you enjoy the trip to jail because breaking into things is illegal even if intended to help.

I think it's safe to assume one would get permission first. There's nothing wrong with demonstrating that a "gaping security hole" leads into the vault to bank management; especially if you're one who has a job relating to security.

Put the "fear of god" in them? Seriously? If you walked into a bank and saw a gaping security hole that let you enter the vault - would you demonstrate it by entering the vault? If so I hope you enjoy the trip to jail because breaking into things is illegal even if intended to help.

I think it's safe to assume one would get permission first. There's nothing wrong with demonstrating that a "gaping security hole" leads into the vault to bank management; especially if you're one who has a job relating to security.

If you got permission BEFORE then sure. But you don't get to dictate how they handle their security. The attitude problem of a lot of technical types is too often one of "I found something so you must care about it too. And spend your time listening to me blather on about it. And spend your money fixing it. Cuz I found it and I'm excited about it and I'm too aspie to consider your point of view"

I love it when dickwads get arrested and sent to prison for years because they decided to exploit some vuln in someone else's property. Because they seem to think laws and rules don't apply when they're excited about something (eg purported secu vuln).

*dons a black hat*Release the website and the client's name on various well known internet watering holes for defacers and digital malcontents. Then sit back and laugh as the script kiddies take down their site and you are paid handsomely for a hurried recreation of their web-applications functionality, but this time in a secure manner.

*removes the black hat*Or as has been stated above a number of ways. Evaluate what this contract means to you, approach the board with your findings in a very factual manner, doing your best to avoid jargon, and remembering to the average person even the work jargon is jargon. (So is the word memory leak, and the word exception, and don't ever say "illegal instruction set"). Possibly offer to do a full code audit with relating estimate.

Then await their reply, if their response doesn't line up with your personal and professional sensibilities based on the earlier evaluation, you simply say. "I'm sorry that we have wasted everyone's time, but I am not capable of proceeding on this project within the given parameters."

The links for "sql injection" and "business logic" are super unhelpful, which is a trend for these articles. Please link to a page actually explaining what these things are.

SQL Injection is, to simplify, when the user input goes directly to the database, allowing a malicious user to make major modifications to the back end database by using SQL commands. Example:http://xkcd.com/327/

Business Logic is data manipulation code, like proprietary calculations or transforming things into custom objects. It's often a layer of code between the code that writes to the database (which this project is apparently lacking in any reasonable form) and the code that handles how the data is presented to the users.

CYA department: There's always the option to demo SQL Injection either in their test environment or one you set up for the demo. This explains the problem visually, and then you can show them how the same exploit is in *their* code.

I don't think setting up a demo of SQL injection vulnerability is constructive at all. I think more often than not it would come off as overly aggressive and unnecessary. Putting the "fear of god" in a new client is no way to build trust especially if you're not being brought in to respond to a disaster or emergency. With my own clients I sometimes run into situations where I think their environment is messy and poorly implemented. I could think of dozens of ways in which their network is one failed switch, disk, or power surge away from an irrecoverable disaster but to them its been more or less working fine for years. Worse is when you alert them to what you think is a Big Find that in your mind is worthy of a parade in your honor only to find that the client is totally uninterested.

I think your case is pretty straight forward since you've quoted them more time than expected and they asked you why that is. I would just be honest without pitting yourself against the previous consultant. I would explain that coding, like other tasks, can be done in different styles but the end result is the same. In your professional opinion, their current code is messy and not thoroughly documented and does not follow best practices. While it technically works, it will take you more time to make sense of it. You would also like to point out that they should consider having the code rewritten because A) there are some potentially serious security concerns and B) because the code is not neat and organized any future changes they want from you or others is likely to take more time (and therefore cost more) than if it was cleaned up.

Beyond that, there isn't a whole lot more you can do. Ultimately it's their decision. If you absolutely need to give them concrete examples, perhaps you can take a small section of code and show them what theirs is and what it should look like. This is more work for you which may or may not pay off so it depends on how badly you want them as a client.

On another note, does vulnerability really need to be shortened to "vuln" ;-)

You don't always have to fix other people's mistakes. Someone wrote that original solution. If that person was a professional(loose usage) there may be a duty to have done it correctly the first time. SQL injections are not a new problem and would have been known to even the least competent developer even 10 years ago. Assuming the developer just didn't use the programmatic way of doing things the first time, I would consider elucidating with the concept of “you should threaten to sue people” who incompetently design websites. Some of my first few questions would be:

1) What were the terms of the initial development contract?2) Was there a support contract involved?3) Do they have a local attorney to write some mean demand letter to the original developer?4) Do they know about the risks of not correcting certain problems?5) How long has the site been up in its current form (assess current risk something has already happened)?

After that, just use plain English to explain how serious the problem might become with SQL injections. That SQL injections means that a ne'er-do-well can and will access business critical information, financial information, etc. and may put them on the hook for significant legal risk. Show them what it will take to fix something on one page, let them know that it is on x number of pages. The fact that stuff is all over the place is common in poorly written .NET projects, and unfortunately I assume it to be par for the course when ever agreeing to give an estimate in the past. If the database is sufficiently standard and you are going to be redesigning some look and feel elements, consider transitioning them to some kind of standard CMS/eCom/etc solution. That might kill two birds with one stone. I mean templating is pretty easy with .NET so you might be able to spend a couple of hours and get the same functionality from similar HTML. Finally, do the math for them. Let them know the must fix, the need to fix so you can do your job, and the would be nice to fix.

I turned down some work this week. I told my client they were smoking crack. Politely. I explained what the issues were and why I couldn't accept the work, which boiled down to I couldn't deliver several months work in 5 days, the deadline they'd invented without looking back at the history of the system's development.

In the case in this post I'd spend, with the client's okay, a day documenting the issues with some estimates. Including a link to Little Bobby Tables is an option, depending on your client's sense of humour. Including some examples of wacky stuff you can enter in fields might help: <script>alert('xss')</script>.

I've seen this from the other side. We had a software consultant programming a machine. At one point, the machine literally crashed (didn't observe limit switches). We already knew something was wrong with the original code when we called in another consultant, but couldn't believe his estimate. For repairing the software he wanted more than the original developer for creating it. We sat down with him and he explained to us in fairly technical terms what the problems were. Not only what led to the crash, but was wrong with the code in general and what he had to do to fix it. We didn't understand everything, but the message got through. We hired him.

What you should do as a consultant in such a case? Explaining it is definitely the basis for all, but it also depends who you're talking to. If you have a technical contact at the company, convince him first. If you are only talking to business or even worse, purchase department, you are probably screwed. You can ask them to sign a liability waiver, this often gives their legal departments the shrieks. This way they might cancel the job with you, or agree to your terms.

One of the commenter on the article says this "In their mind, the application is running great". When the site runs good and everything runs smoothly and so by convincing him the codes are bad is not a good way to go about it especially the client knows nothing about coding. So here's my suggestions:

#1. First of all, never, never criticizing other people's codes to your clients.

Let them know yours is just a "little bit better and a more stable way" of running on their sites. Be "humble", not "BS". When you think you are smarter than him because you know the codes better than him and so may be BS him a bit or even scare him a bit is okay and you are thinking he wouldn't know the differences anyway. Oh yeah, think again, he knows, if not for now, in the future he will, and he would find out that you have BS him and scare him. So it's not a good way to get started that way. Words get around, remember that.

When you tell them that the old codes "sucks". They think you want their businesses so bad and mess with his intelligence. Bad news. You might ended up an appositive result that you would regret it. So criticizing other's works is a bad start even if those codes really, really suck big time.

If you are that client, would you trust someone who knows only complaining others works? It won't be me, I would trust him.

#2. Get his trust. When you got his complete trusting on you, time you have spent on that job is not an issue any more. It's all about money, right? When time is not an issue to that client because he trusted you, money is not an issue either. But remember this, if you want his business in the future, or may be friendship and this is not a one time deal for all of you so don't be over-charged him too much. Even this is a one time deal I still would charge him a fair price.

#3. You want his business so be sincere. Honesty is a must have on any type of businesses deal. Convincing a person on a business deal to go about your ways and your ways only is not an easy task.

If you don't have that "nice and honest face look", find someone else has it. An honest face get you lots of businesses. People make good money doing PR works, right? There is a trade for that. It's all because they have that God gives humble, honest and good look.

Those are the extremely lucky guys and girls I tell you. It's a specialty not everyone can handle it well.

<After I finished the last line, I took a good look at the mirror. Hmmmmmmmmmmm...." Oh, well, no comments. :-)

For scripting languages, I think the "your code sucks" is harder to prove.

Step back to the normal methods that should be used by all developers.* Bug and Feature tracking systems* Unexpected behaviors* Crash reports* Code complexity tools* Ugly code - there is something to be said for code that is simple and properly indented.* Long, intricate code - any method/function over 1 screen in size is too long.* Hacking tools - nexxus

I know that for C and C++ there are tools which can help prove the case. Code checkers, memory leak finders like "Purify", runtime function call locators like "Quantify" (I've seen Acrobat Reader hit the gettimeofday() call 10,000 times in a second using system trace tools, strace. That is the definition of "crap code."

We all wrote crap code at some point. Only experience leads to beautiful, elegant, clean code. Some of the stuff I wrote last month sucks, but because I use TDD, I know that the functionality is working.

The employer probably doesn't care about anything other than functionality that does not work. Security of their website doesn't mean anything until there is a real loss. That is human nature.

If they are asking why so long, just tell them. Give them a list of the reasons why, and keep a detailed list in your pocket (if you have already taken the time to detail it). I was doing some consulting for a cable company a couple of years ago on the side and encountered the same situation - a home grown PHP application (they could have simply used one of the common packages out there - like joomla - since their site was not complex at all) with hard-coded business logic and even multiple chunks of code doing the same thing with slightly different content. Their old consultant also buried data in a database which they would not give us the "write" password for. In the end I said "this is what I can do for you and this is what I cannot do for you and this is how I will have to do it and here are the reasons why I have to do it this way." Of course I had a savvy, silver-tongued partner who could smooth over my engineering brashness.