Clinton Reeves / Posted 11.29.2016
How to tell if your developer is BSing you
It’s fairly safe to assume that at some point everyone has been on the receiving end of a load of BS. Sometimes it’s pretty obvious. But what do you do when it’s not? What do you do when it’s coming from someone you or your business depend on?
In the tech industry, this is a particularly difficult issue to deal with. Writing software, building websites, and programming in general aren’t things people “just do”—it can take years to amass the knowledge and skills needed to do this type of work properly. This is, ultimately, why you hired an expert instead of doing the work yourself. In doing so, you expect to rely on the experts to get their work done and to provide you with sound advice in areas you may not know much about. But that doesn’t always happen. So how can you tell if your developer isn’t being upfront with you, and what can you do about it? Let’s take a look.
Are they getting work done?
Nothing says more than proof of progress. I don’t think I’ve worked on a single project that hasn’t had regularly scheduled status updates throughout its lifespan. Whether these come in the form of specific milestones or quick check-ins, there have always been points along the way to show off “where we’re at.” And in truth, there has never been a time where there hasn’t been something to show, because even something broken is something.
If you find yourself hearing a lot of “I’m working on XYZ” or “I’m just finishing up PQR” but haven’t actually seen quantifiable progress from your developer for a while, this is a pretty good indication that something is up. This is particularly true if the project or task is already late.
When in this situation, remember that you can always make a very simple request: “Can I see what you have thus far?” Do be aware that many developers can be hesitant to share, especially if things are broken. Reassuring them that you don’t care if there are problems, but just want to make sure that progress is being made, can help you get past this hesitation.
Sometimes, promises or agreements may seem to be overly optimistic or even impossible to achieve. I liken this to a building contractor saying they can build you a brand new, two-story house from the ground up in one week. Like many folks out there, I’ve never built a house—wouldn’t even know where to start, to be honest—but just thinking about the very general, high-level processes that go into building a home makes it pretty easy to see how far-fetched the contractor’s promise is.
Since this is your web project, I assume you have an idea of how large or small it might be. So, if you find yourself looking over a proposal that includes a 30-page list of itemized tasks and the developer claims, “It’ll take me about a week,” you may want to take a step back. You don’t need to know everything about the development process to know when something sounds too good to be true.
Talking down, or nonsensical technical jargon
“Yeah, uh, the geosynchronous orbit of the singleton class was borked because of a change at the ISP, so we had to nuke the DNS SDLC. It’s entirely too complex for you to understand... Flux capacitor…” Okay, so that’s a bit extreme, but it brings up two very important points:
- It’s needlessly complex (to the point that it appears to be intentional)
- It makes the assumption that the person reading it wouldn’t understand even if the developer did explain it in more detail
When I was in college, I had a professor who repeatedly told us that we needed to be able to explain what we were working on in words that your grandmother would understand—the point being that developers need to be able to communicate with their target audience. Yes, we do have to deal with lots of complex problems, but that’s the case for all professions. Likewise, statements like “it’s too complex,” or “you wouldn’t understand,” however true they might be, are irrelevant, and offensive. Who are they to say what you will and will not understand? If you are their client, part of their job is to make sure you have the information you need, not the information they think you need.
In the end, in my experience, the only excuse for responses like these is to 1) confuse or intimidate the client in hopes that they don’t ask for additional information because it might reveal a lack of progress, or 2) to hide the fact that the developer doesn’t really understand the issue themselves (this does happen). Both of which are definite signs of BS.
Sometimes, things just don’t seem right. Maybe it’s something they said, or a series of actions (or lack thereof)—either way, you’re feeling uneasy. If you have a gut feeling that you’re getting fed a load of BS, make note of it. That’s not to say you should make any sudden or extreme decisions, but keep the feeling in the back of your mind. You may not be able to pinpoint it right away, but with a little bit of time, you will likely start making sense of it.
The phrase “bullet-proof”
In the last couple of years, the phrase “bullet-proof” has become a personal pet peeve—and also a huge red flag that I watch out for. I honestly think it should be banned from the software industry. Any time I hear someone say it, my BS meter is instantly off the charts. Every project I have encountered where that phrase was used had some sort of disastrous issue arise. It’s like an instantaneous hex.
Witchcraft aside, the phrase itself isn’t the problem. The problem is the reason it gets used. From what I have seen, it tends to come up when someone is trying promote the stability and/or reliability of a particular technology, but they lack a full understanding of how it actually works. The phrase then becomes a catch-all that allows them to breeze over the most basic, high-level information and still emphasize how great it is. Don’t get me wrong—you may not always need or want detailed technical specs about Product X, but watch out for excessive usage of superficial statements.
So, what do you do?
Thus far, we’ve covered several different ways you can determine that your developer is BSing you, but what do you do if you find yourself in this situation? Fortunately, you do have options available. If you’re prepared to spend a little bit of money, one of the easiest options is to simply get a second opinion. There is no shortage of experts in this industry, so take a little bit of time, find one or two that you can consult with, and see what they have to say.
Above all else, don’t forget that you are the client and you have the right to ask questions. If something isn’t sitting right with you, make an effort to get to the bottom of it. When speaking with your developer directly, one all-around good question you can start with is “Could you explain that to me?” If the response seems wishy-washy or skirts the issue at hand, you’re probably getting a load of BS. On the other hand, you may find that they have a detailed understanding of the matter, setting your mind at ease. Either way, the responses they provide to your questions are going make that determination. In addition, you can also run these questions by an outside consultant, and see what they have to say.
Clinton is a back-end developer at Q Digital Studio who lives and breathes code. He is Q Digital's resident problem-solver; if he can't fix it, he'll just create new code or a shiny new add-on. When he's not problem-solving at the studio, he's likely tinkering with an arduino project, or working on his house.