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?
Related: "How can I explain SQL injection without using technical jargon?"
Walk-throughs will work
Karl Bielefeldt answers (116 votes):
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.
Related: "How to explain refactoring to a non-technical person?"
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.
reader comments
56