What are the most common lies told by programmers?

It is about trust.

Trust is sacred when it comes to developing a website or software. You go to programmers to make your development wishes come true, through languages and forces you do not understand. It is an expensive process, and the future of your business can be hugely affected by how the final product turns out.

If you are hiring a program developer, it is very likely that you do not know much about programming yourself. At its core, programming itself might seem like a mystery. When you do not understand how it is done, distrust can be easily bred.

The development process is almost invisible to anyone but the person writing the code. Programming is far from constructing a house. It is easy to understand how much time construction takes when you are able to see the foundations being poured. Sadly codes are not as apparent.

Without any prior coding knowledge, you might be feeling vulnerable, and well you have all the rights. When you do not understand the process of making something, anything seems plausible. You can be easily lied to.

Of course, it is important to build the frameworks of a relationship on trust, and not paranoia, but having prior knowledge of a few common industry lies does help to make you feel safer. So, here we are with some excuses that developers are likely to use. 

Common lies often told by programmers

People often go to developers with extremely high expectations, led by a lack of programming knowledge. Here is where the biggest issue happens. One should remember that programmers are salespeople. They want to keep you no matter what. Most of them prefer to deal with the consequences after the contract is signed. Here are some lies you might encounter through your development journey.

“It worked.”

The first on our list is one that should not be taken too hard. It is not much of a lie, but more of an excuse or sometimes, especially if you are working with a less experienced team, even an honest presentation of confusion.

This excuse can be said in a multitude of ways and manners, always in the same situation: something that was tested before is not functioning when used by others.

This happens for various reasons. It might be due to inaccurate testing, or polarization during testing. In the case of polarization, the feature might have been used in only one direct way, but then the final user was left to improvise.

The developer just cannot believe it. They tested it and it was fine! Why isn’t it functioning now?

Errors due to inaccurate testing are fairly common in programming. A mature and experienced developer looks at the issue as a problem to solve, and not a wonder. Nobody is trying to deny that the feature probably worked at some point, but now there is a bug that needs to be solved.

Guaranteeing that the software will solve the problem

Software is a powerful tool. Nowadays anything can be done by software. We see it prescribed for issues as it is medicine. Need to set a schedule? Use this software. Your system is running too slowly? Use this software.

Although it seems like software is capable of solving any issue, the software is merely a tool. If it is not used efficiently, no software can be that helpful. The software cannot save a business from falling to pieces, just like how a plane cannot fly itself.

Young developers are fascinated by the power of software. Some truly believe that any problem can be easily solved through the use of the right software, while it is way harder than that.

 It is not about the tool, but how efficiently it is used. The most commercial package carries way more than you actually need. The roots of a business dilemma lie in the belly of the company. Before any tool can be adopted and used, the needed framework needs to be constructed. The change must be supported through training and culture nurturing.

No software can miraculously save your failing business if your product is low quality, your staff is under-trained, or your brand is too weak. Software solutions can be of great help, but keep in mind the needed steps to make them effective.

Under-promise, over-deliver

One could argue that this is technically not lying, but it can still be reviewed as a way of manipulation. Programmers might use this to lighten the burden of upcoming possible responsibilities. If the work they are doing seems too easy, they might be given more tasks or paid less. But if it seems like hard work and they over-achieve, they will be adored, get amazing references, and maybe even a bonus.

This is why we always emphasize the importance of contracts. When the plan is clear and the tasks are set, issues like this are less likely to occur. Setups, where the software is basically improvised and created along the way, are the best for this strategy.

The client’s responsibility in such cases is to, first of all, set a contract as clear as possible, and then be understanding of the programmer’s work. You have discussed what you want, and they have discussed their price. No work is little work. If a task gets done fast, it is not a reason for deeming it unworthy or easy, but a good opportunity to appreciate good work.

“Anything is possible, and we can do it all. We just need the right amount of time.”

No development firm can do it all. This answer is usually said after a complicated request has been made. As we have already said, developers are salespeople too. They do not want to disappoint or lose their client.

Obviously complicated projects take way more time than less complicated ones. But time is not the only mattering factor. Experience and competence are needed as well. Most programmers find it too hard to accept that something is too big for them.

“It is impossible to do that!”

The client has a new idea. “Can you make the software perform x?” The response is a “no”, or a “that is impossible.” But the truth is that the programmer finds the idea inefficient. The idea might just take too long to be worth it. It might also be too expensive, or that it is simply an awful idea and will ruin everything.

The developer might doubt you, your financial capabilities, or that you will still even want that idea after they are done. Sometimes you are having too many new ideas and making too many requests that are not mentioned in the contract. This “no” is a way to sound less impolite or harsh, and decline the request more smoothly.

If the company you are working with must be flexible and open to new ideas through the development process, make sure it is clear to them before you even write the contract. Make it clear in the contract that you might want to change the plans during the development process.

While everyone is responsible for how they answer a request, the way you state your request can bring out honesty. Share your idea. Ask for their opinion. Ask about how implementing that idea might affect the other features. Do not think of the development team as your tool for getting to the software you want, but your partners and coworkers. All other ways to look at it lead to disaster.

“I have followed test-driven development approach.”

It is like telling your mom you have cleaned the room, hoping she does not find the dirty clothes you tossed under the bed. While continuous testing might be of vital importance, it also feels like a chore to most developers.

Many might not test as frequently as they should spend less time, or because after some time coding, they found themselves making way fewer mistakes, so they accept the risk of putting it off.

But if you are hearing this lie, it means that something probably has gone wrong. Does not matter if they have been testing at this point, they have to find the bug, and fix it.

 The best solution to this problem is to not let it happen in the first place. You can deem certain people responsible for routine tests including the whole team. You could also ask for all test results to be documented. This way even if something goes wrong, there is an archive to look at.   

“Oh, trust me on this.”

Two-worded sentences such as “don’t worry.” Or “trust me.” must raise alarm bells.

The problem here lies in quick answers, and minimized issues. Of course, every colleague should be trusted, from the least to the most experienced, but questions deserve detailed answers.

It is natural and smart to think about the logic of cause and effect. Do you believe nothing is going to happen? Do you believe there were any consequences?

When problems occur it is hard to get a wider and more detailed point of view. Everyone is bound to their experience and knowledge. So every team member has to be communicative and share as much information and detail as possible.

Communication helps the teams to understand details more thoroughly and let the real issues come out.

“But it works on my machine!”

Sometimes this is meant to be believed as pure curiosity, sometimes it is blamed on the difference of equipment. Either way, it is a very commonly told lie.

It is highly unlikely for software to run on one system and not the other. Even so, it is not good for the software to run on one system and not the other, especially in the case of websites, CRM, and eCommerce solutions. It is a very serious problem that must be instantly addressed.  

“It is neater.”

People look at coding as a magical, impossible to understand, and complicated progress, and this is the source of most programmer excuses. This excuse is usually used to convince you to go for a length option or complex. No more logical explanations are provided, but that it is “cleaner”.

The software does not do neat and nasty. We have stable reliable solutions through the right code, and there is unstable and tricky software that can create a lot of problems.

Even if you do not understand programming languages, you deserve an explanation when you are told it is better to follow one path than the other.

“I am not responsible for this, they are!”

In this excuse, the responsibility can be held by another person, team, or thing. Some common excuses are “somebody else did this”, or “it is because of the hardware”, or “it is a back-end affair.”

While this might not be a lie, it is an excuse, and an awfully wrong way of approaching teamwork, let alone software development. When facing a collaborative project, with multiple teams present, the software is the common mission. It is the common interest of every single person present to finish the project on time, create a suitable and successful software solution, and get paid.

It is bad teamwork to move the responsibility to another section. While it might seem like the easier thing for a programmer to do, it will end up right back in their face. It is important to communicate and speak about why certain errors happened. While every section must take responsibility for the errors happening on their part, all team members must work together to solve them.   

Many projects face great issues because of this. This situation is very common as usually, two separated teams (frontend and backend) work on the project. It is even more common if you go for offshore development.

The correct response here is to not just blame the problem on others, but help them better understand the issue. When someone says that it is not their fault, they should be trusted. But further steps are required. They should be expected to communicate the issue with other team members, and actively be in search of solutions. It is not only a question of responsibility but also commitment.

“I will have this discussed with the programmers/my boss/manager.”

A great way to save time and take pressure off of their shoulders for many. The customer is told that the developer will try their best to get the issue across to the programmers or the boss. This is usually a strategy to delay having to face the problem and not be as harshly blamed or pursued to fix it.

Employees and team members might have more authority than what they show. You might remember this strategy from your middle school days yourself. Any of us might have told a friend our mom does not allow us to stay at their place tonight, so we would not be blamed.  

It will be assumed that the team member is not responsible for the problem, or that they are trying their best. The created delay might be heavily damaging to the software development process, and the business itself. We always make sure to pursue what the programmer has done about the issue, even after they’ve said they will get it across to their boss.

It is the code you have to listen to, not the developer.

This is not about honesty. Of course, you should respect and trust the person you work with. This is about how complicated and detailed coding is. There is a long way between theory and practice, and many things can happen in between.

When working on big projects, no one can know all the things one might have to know. Misunderstandings happen all the time. A programmer might do something without any understanding of the business logic, creating errors.

The project manager must understand a developer’s work, and explain why and how things need to be done. Going task-oriented (do this after doing this), can work if the project is very structured and has error-proof task descriptions.

But isn’t it just more fun to choose the path of teamwork?

The developers confess

Simply listing possible lies is of no help after all. There are infinite ways to lie, and it is way more fun to hear the lies right out of the developers’ mouths. Here is a list of confessions the developers personally made, of the lies, they tell the most.

Miles:

“The most common lie I say all the time is: “Hey, I just reset the cache. Please try again, it should be working now.”

The truth is I have no idea what has happened. I am probably just buying time to figure the problem out, or ignoring it hoping it will solve itself.”

Kenneth:

“I find it most interesting how the question “can you do this?” is answered by two completely different lies.

The junior programmer answers with a quick “Of course!” and spends the next two weeks trying to learn how to do it. They might not even have the slightest idea of how the request can be done, or even know what the words and acronyms mean.

But the senior programmer usually answers with an “Oh, sorry. I do not think so.” They know how to do it, but they are also aware of the tedious pain and suffering it takes, and they know the end result is most probably not that important in the overall outlook of the software. They might also say no to avoid working with some people. They might even have all the reasons at once.

I have personally used both untruthful answers to this question throughout my career as a developer. Does everyone have a right to know the truth? Sure. But man, didn’t it make my life a hell lot easier.”  

Geoffrey:

“Well, most of my programmer lies are told to my dear girlfriend. Whenever she asks if I am free to go to the mall, or to her friend’s party, I just put together some technical words: “Sorry honey, I cannot leave in between coding the algorithm for our next social app. Oh yeah, I have to stay home all night.”

Works like a charm.

Jokes aside, here are some I actually tell my clients:

– Last time I checked it, it worked! (It has been very long since I last checked it.)

– Just restart your server. It will work just fine. (I am trying to find a solution as you restart.)

– The server is done, just a moment please. (I screwed the code and now I do not know how to fix it.)

It is all just to avoid drama.”

Dennis:

“I think we all tell lies to try to avoid explanations or at least make them easier.

I used to work as a software team leader for a boss who was familiar with programming, but just the wrong amount. His knowledge of software was very limited and often drew him to the conclusion that it is easy to code. This led him to allocate a tiny budget for the software group to develop the final, production-quality software, as the prototype “did just fine.”

Of course, all of us software developers understood that the prototype was not designed to be maintained, supported, upgraded, etc. It was low-quality work, and presenting it like that would mean disaster.

Now, our boss had a background in electrical engineering, and I had seen many prototype circuits in the lab with blue wires. The reason behind the color of those wires was partly so one could tell a prototype from a production-quality circuit board.

So on the day of the big review, I colored some of the lines of the software’s key functions with a very light blue. When I was presenting the software, I ignored all the blue lines until he asked why the code was in two colors. I explained to him that it was just like the blue wires in electrical circuits. They needed to be cleaned up in a product redesign.

He believed me and gave us enough money to pull the project together.

I do not regret the lie.”

 Brock:

“Well, my favorite lie to tell is that I am incapable of doing a client’s request, while it is completely untrue. Most of the requests clients make are manageable, but there are multiple reasons we wouldn’t want to do them.

• It would take too much time and effort for little to no payback. Sometimes the client asks for the strangest things. “wouldn’t it be nice if it could also do this?” well it would Karen, but it would hold back all the other things that we need to get done.
• It would be too expensive for the client. They would not be able to afford it. Impulsive ideas are a programmer’s hell, especially if they are matched with limited knowledge of programming. Just because your idea indicates a small feature or change, it does not mean it will take little resources as well.
• Their idea is awful. They might not be able to pay for it. No one else would want to buy it.
• They do not do what they are asking for. They are not going to even like it. And by the time we finish it, they won’t even want it anymore.

It is way easier to just tell them we cannot do it. No one gets insulted, and no one’s time gets wasted trying to convince or be convinced.”

 Mithur:

“Here is the problem that leads to us lying: if you are a programmer, ultimately everything falls on you.

In the best-case scenario, you have made a mistake, which you will fix. But it is mostly you are making up for the mistakes your boss has made, or the mistakes that are because of a wonderful idea the client all of a sudden had.

In order to survive, a good developer has to learn to “manage” the people around him to avoid disaster. No one cares about what the developer has to go through, because they know they will not be paying the price.  

This is why most developers lie, blame other people for what they were responsible for, hide stuff, or deceive. Then they might get to be the boss someday, and have another programmer fix their mistake at three am to meet the client’s deadline.”

Saurav:

“I am not personally guilty of this lie, but I have heard different versions of it told all the time.

After asking a person what type of a programmer they are, you receive an answer such as “full stack developer.” Proceed to ask the same person about the frontend framework they use and they will not be able to answer the question.

People are extremely obsessed with fancy terminology. Programmers lie about these because they believe listening and reading about that stuff will make them be just that.

They also commonly abuse these titles as they sound good to the clients. How can it be harmful after all, if the client did not know what the word meant in the very first place?”  

Lies you might have been told about programming itself

Being lied to by your development team member is awful. But preexisting misconceptions about software development can be even more dangerous. The stereotypical view of software engineers and exaggerated expectations are more common than you might imagine.

We found it unfair to only speak of what lies you might be told, but not the previous misconceptions you already might have, so here is a list of software development myths.

There is a programming language hierarchy

Programmers love to praise the programming language they use. There is this competitive “rivalry” between people who write different languages, so it is very common to hear that one language is way better than the other.

The truth is each language serves a specific purpose, and has its own pros and cons. Saying one language is better than the others is almost as absurd as saying German is better than Arabic. It depends on where you live!

It is the same with programming. Different languages are suitable for different tasks. Sometimes a task requires the use of multiple languages, to achieve the best results.

The programming scene is made out of languages working together, not competing against each other.

The bigger the team, the faster and better the progress

This misconception is most common among managers and clients. It is often falsely believed that if the planning phase fails, more developers can be later on added to the team to aid with the development process.

 This misconception is based on how development is often viewed as mechanical processes such as manufacturing and house construction. In reality, development is sensitive and based on delicate teamwork and harmony. All the team members must have certain knowledge about the project and be aware of the workflow, and some of this knowledge is only acquired by being present from the beginning.

This is why adding more people to the development team in the middle of the process is almost always an awful idea. It can lead to more chaos, more errors, more costs, and more delays.

The time spent on trying to communicate with the new team members and explain what is going on, is time not spent on the software. The only way you can get good results from adding new team members is by acting carefully and in a well-coordinated and planned manner.

Remote software developers bring chaos

This is a very old-school way of thinking. One that believes if an employee is out of your sight, communication is impossible. Some believe that a remote developer cannot be managed or in other words, controlled. They believe collaborating with a remote developer guarantees poor results, as the developer will be irresponsible and lazy.

 Of course, this is not the case at all. Long-distance partnerships and remote work have a long tradition in the tech world. Remote work is very well supported by tools and company support, and the circumstances are only getting better. The pandemic left no choice for us all to get more familiar with long-distance work. The culture is flourishing more than ever. Many companies even decided to give their rental base up.  

Modern project management practices, accessible and easy-to-use communication tools, and project management systems make it easy for people to work together from any distance.

Remote teams care just as much about the product they are developing. It is way more common to outsource than to go in-house at this point. Established outsource providers have a long list of references. The success of their client’s software matters to them more than anything.

 The truth is that remote work has proven to be a reliable option and an enjoyable experience.

Development of a software is a linear and also predictable process

Another misconception is rooted in thinking that house construction and software development are all alike. They are not. When developing software, sticking with the blueprint is not going to guarantee that nothing goes wrong.

We do not mean that no development process can be straightforward and smooth. Smaller, short-term projects are more predictable. You can almost always finish a landing project before the promised deadline, without facing any issues. Here fixed price contracts work the best. When the contract is clear, there is no misunderstanding between the parties, the team communicates regularly, and the right technology stack has been chosen, it is hard to go wrong.

But that is not always the case. Nowadays, development teams around the world prefer to use methods that are more flexible and less predictable, such as the Scrum framework.

 It is rare for a development team to be able to accurately estimate the time for a project. This is why there is so much focus on planning and thinking about each other functionality as early as possible. And to be honest, the project requirements rarely stay the same during the production period too. The world is changing faster than ever. Internal and external factors can both affect the development process.

 Keep that in mind, and expect the unexpected.

All programmers do is write code.

No. We do much more. You cannot design and create a tool if you do not know anything about it. The software development process is far more complex than writing code. Software is created for all different kinds of purposes.

 For the product to function and achieve its goals, the developers need to understand the subject area. It is common for developers to research the domain before starting to code the software.

Developers are usually curious people. They embrace the field they are programming software for. For example, developers who specialize in blockchain solutions know a lot about finance.

The development process should go as fast as possible.

It is not a good idea to rush things in any field, not only development. Dedicating time to communication, planning, gathering requirements helps the process go more smoothly. One must remember that when the solution is ready, the development process has not ended. You will have to maintain the solution, update it with new features, and support the users.

It is good to maintain momentum, but rushing things guarantees bad results. Forcing the programmers to work overtime and skip key steps is a mistake you will regret.

You can add and eliminate features easily during the process

Agile should not be mistaken for working without planning and documentation. It is a common belief that basic requirements are enough to start the development process and all the other features can be changed and added in the due course.

If you start a project without clearly knowing what you want, you are going to waste money, and you are going to waste time. Not having clear goals can even lead to project failure. Correct documentation of the process helps avoid mistakes and makes communication easier as well. If the requirements are unstable and keep changing, the team cannot test the software properly before presenting it to the market.

The core should be well planned, but you should always leave some room for change.

Testing can be skipped

 The importance of quality assurance experts and testers is often overlooked. Many assume they are not critical to the project’s success. But the truth is testing from the early stages is what determines the success of your product.

Many software firms give up on testing as they find it too time-consuming and expensive. That is while with test automation you can reduce development time heavily, and effectively measure the software quality during each development stage, through the use of QA mechanisms such as code review.

The plans are going to keep you safe from any possible error  

Planning is obligatory. You cannot develop any software without proper planning. Development requires a lot of attention to detail and coordination. Without diving into the details and thinking every possibility through, you are basically putting yourself up for a huge failure.

But plans are not necessarily to be kept. Sometimes things do not go according to plan, and sometimes plans need to be changed. Requirements might change over time, and the developers might need some flexibility. Plans should be looking at initial hypotheses that need to constantly be revised, and not rigid law.

Your requirements are more likely to change during the process than not, and sticking to the plan is of no use if the software outcome is no longer valid in the market.

The product is done, the project is done

The software requires maintenance. Just like a living organism, your software will fail without the proper care. It has different needs during different development phases, and the world around constantly changes as well. The market, the business, consumer trends, and technology are all ever-evolving.

New functionalities, updates, and improvements are going to be needed. Releasing the product is not the end of the project, but a change of what needs to be done. You will be thinking of ways to improve the software, doing customer service, addressing bugs, and maintaining what you have created.

What does a software development company do?

A software developing company or team has a goal and it’s to design and develop a custom software application, framework, or tool to solve a problem or to get a specific achievement. 

Dewzilla is one of the best app development companies that can help you. You will get what you need at its best. 

In conclusion

Our intention in writing this article was not to create mistrust but to delve deeper into what may create dishonesty between the client and the developers.

 We hope to have clarified some of the common lies told by the programmers, the reasons behind them, and lies and misconceptions about the development industry.

No teamwork is possible without trust. The best way to dispel the myths and prevent lies is to be down to earth and communicative. Do not demand but communicate what you want. Ask for the developers’ opinion, they are experts and it is only through the sharing and discussion of ideas that the best outcome will be achieved.  

FAQs