Здесь что-то не так... (@ Джин Сильвер, 1883)...
Прочитать позже

How programmers deceive customers. Typical tricks programmers list

How programmers deceive customers. Typical tricks programmers list
Is there something wrong... (@ Long John Silver, 1883)


Surely every person making their own web project has had situations when it seems that something is wrong here. Here we will analyze the typical possible tricks of cunning programmers who want to warm up a little on a simpleton client. We will also suggest how to organize work with a team of programmers in order to minimize the risks of becoming a victim of fraudulent programmers.

We do not pretend to the completeness of the list, but for most projects, understanding these tricks will already close the bulk of the risks in terms of deceiving programmers. Not all of the described moments are deliberate deception. Some of them are just implicitly beneficial to the programmer, but harmful to the customer's project.

Hiding possible problems in the future

The program can now work well passing all the tests. But it may be that rogue programmers deliberately go on an internal crutch, which on a large amount of data will just fall. They either don't know how to do it right, or are too lazy to look for a more correct solution, or intentionally make a weak solution (for example, offended by the customer for something). This is an extremely unpleasant moment, because it is difficult to identify it at an early stage.

What can help?

  1. Testing on a large volume - you can spend some budget on creating a large array of data in the database and test the application in such conditions.
  2. Perform load testing using additional services. This will allow you to understand how the application behaves in a situation where many users are accessing at the same time.
  3. Analyze the source code with the help of a technical specialist, look for problem areas.

Important. You should not think that your developer is a dumbass or a scoundrel, if in the end problems were revealed during the test.  It is necessary to jointly develop an action plan for problems and solve them promptly, it is impossible to foresee everything in a complex application, but you can be ready to solve emerging problems.

Binding the customer to yourself

How do super expensive developers appear? These are the ones who support super-large systems, and no one else can figure out this tangle of code. The systems are already making money, and this whopper should not stop. Therefore, any money is paid to someone who is able (or says that he is able) to cope with it.

In such cases, a situation arises when it is extremely difficult to change the programmer, he implicitly dictates the conditions for the development of the system (just saying: "Hush, this should not be done in any case!"). This is an extremely unpleasant situation for the owner of the product, because he essentially finds himself in a strict dependence on a particular person.

In the case of our platform, we reduce this dependency for the product owner as follows:

  • to support the product, you do not need to know alchemy, you just need to know SQL and HTML;
  • we have very detailed documentation on the platform with a demo stand and examples;
  • the client's website is not tied to the center in any way and can work completely autonomously (for example, in a secure local network).

What can help?

There must be documentation. If there is documentation on business processes and developer documentation, then there is a chance that someone else will be able to figure out the program.

The source code of the project must be available.

If it is not there, then you will not be able to develop your product. However, there are exceptions here: our platform also has a closed code, but a specific project develops entirely on SQL procedures, so even with the platform's closed code, you can develop the project further almost as you like (if the business logic code was closed, then it would be sad for the end customer).

The project should have a minimum amount of such code, which everyone is afraid to approach. If there is such a code, it will definitely have some kind of irreplaceable keeper. And what will happen when he leaves or demands a salary at the level of programmers in the USA? It is better to immediately abandon such features at the development stage. "Be afraid of your desires" is a very wise advice in such cases.

Inclusion of unnecessary functionality in the technical task

Very often, the customer, like an insatiable cat, tries to cram everything into the project. Some even think in such categories - now we will stuff everything in a row, and then we will remove it if not necessary. This is, to put it mildly, an unwise approach.

The fact is that any requirement in the technical task requires additional time and budget for implementation.And every unnecessary feature takes this budget away from the future very necessary feature of the project (a feature is an opportunity implemented in the product).

Even worse is the situation when the manager implicitly inserts some functionality into the technical task, and the client signs without really understanding what is there.

You should always look at the details, and not rely on the opinion of a specialist.

Consider a practical example, you have 1 million to develop a product. You start shoving everything into the project. The project manager excitedly helps you with this, offering everything in a row, chatbots, various integrations, distilling data into some analytics systems, etc. As a result, it turned out to be about 900 thousand. "Great, everything is invested, even 100 thousand left".

In fact, you will (if you're lucky) all this is in the specified budget, run it and you will understand that some things need to be redone, something was not taken into account, etc. and 500 thousand more improvements are required. And these improvements are really needed! This is no longer a fantasy-fiction, but a real need. But you have already spent the budget on dead unnecessary functionality. And as a result, we get a large overspend, and in the most negative case, the project will close, because there is no more money for development.

We kindly recommend you to study our article about technical task for a site.

What should I do so that this does not happen?

Throw out everything that seems superfluous to you and what you don't understand how to really use in the project.

Start from the real needs, and not from the fact that site X has it, so we should have it.

This is the stupidest argument, because it does not take into account your context at all. Another company has other resources, other tasks, etc. If you spend your budget without understanding what you don't know how you will use - you are in danger.

Well, be careful with the advice from the project manager, programmers - they solve their tasks. The manager needs to sell more, the programmer is interested to touch some technology and add a line to the resume. Your product has living needs - and they need to be addressed.

At the same time, this does not mean that you do not need to listen to techical specialists at all. You just need to evaluate everything from the point of view of rational benefits for the project. Anyone who offers some kind of novelty to the project must justify the real benefits that we will receive when implementing.

Blurry description of the task with subsequent payment of disputed points

If the technical task is written very blurry, and managers from the web studio really like to milk the client dry, then a time bomb is laid here.

The technical task must be written clearly.  The more precisely the technical task is written, the fewer reasons for dispute.

Usually a vague description of the technical task is more of an excuse for the customer to bargain for something as free improvements. At the same time, rogue programmers may first agree on a small estimate of the project, so that the client chooses them, then in the middle of the project to say that it turns out that this does not include this and that. And the project is already in the middle and it is difficult to give the client a back.

Therefore, it is necessary to find out at the start to the maximum what and how it will work, what the result will be, to fix all these points in the technical task.

The better the product owner understands the details of the technical work on the project, the easier it will be for him to see the places where problem points may arise in the project.

Therefore, be sure to spend time on the basic study of web technologies, promotion, etc. 

Using "crutch solutions"

I think this is the most dangerous hidden negative effect in the project. The fact is that crutches greatly affect the cost of future development and support of the system.

The more "crutches", the more unexpected tricks your program can produce.

Changed something in finance - fell off in registration. It seemed like it could be related, but then it turns out that there is some kind of "crutch solution" and it was not taken into account with new edits.

Ideally, you need to do the program completely without "crutches". In practice, this rarely happens, because deadlines are burning, the customer wants to complicate everything (especially bad when it does not take into account previous improvements), the developments are layered and there are "microcracks" in the functionality.

How to deal with it?

It is necessary to do code revisions, lay a budget for refactoring, focus not only on working functionality, but also internal quality. Most customers do not think about it at all and are not ready to spend a budget on it. But in the long run, this is what increases the cost of maintaining the program.

Offering the newest technologies

And what could be the catch here? Modern technology is good. It's better to have a modern site than a prehistoric one, isn't it?

New technologies, it's not only cool, stylish and keep up with the times, but at the same time:

  • instability
  • incomplete browser support
  • if a problem arises, it is not so easy to solve, because there are no typical solutions to problems in the network yet and you need to beat your head against the wall to solve them.
  • the newer the technology, the fewer specialists there are for it. The fewer specialists (the offer), the higher the cost of attracting them to the project (and it will not be easy to find them).

And what does the benefit of the programmer have to do with it? What is the deception?

The programmer is trained at your expense. He will fill bumps in paid working hours. If there are problems, this is also good, additional work.

New technology is a new line in CV. It also binds the customer to him more strongly, the risk of dismissal is lower. A programmer may not even think about all the possible problems of introducing a new technology - he is just interested in meeting something new.

But you, the product owner, should understand all these points and not be fooled by the coolness of the next superframe. By the way, we also have a framework in fact, where SQL and Bootstrap are the most common technologies in the Internet.

If you are implementing something newfangled and untested (blockchain, artificial intelligence), be ready to drink more than one cup of shit (in other words, spend a lot of time and money) to solve all the nuances that arise.

Reducing costs by reducing some work

The cost of a web project consists of many details. Some people make a project from scratch, make layouts of all pages separately, then designs of all pages, then layout of all pages, then connecting the layout to the backend.

The development itself can be done in layers - separately database, separately business logic, separately data access layer, separately API methods. Such approaches create a space budget. And this is normal for some types of projects.

We do not make separate layouts, we do not make a separate layout, the data access layer, business logic and working with data in the database - all this is done within the framework of stored procedures.

We are for a quick approach of a series of edits. It is easier for us to sketch a form in Bootstrap with a typical markup than to do it separately in Axure (layout tool). And all this is done essentially by one person, not 5-6. He should only know SQL + HTML in terms of Bootstrap classes. And of course, such a project will be several times cheaper than a project with the approach described at the beginning of this section.

This does not mean that our way of developing is definitely better. It's cheaper, it's faster, and it allows for quick edits.

Someone will say that business logic in stored procedures is terrible. Everything has its price (and of course SQL procedures lose somewhere in the convenience of development to object-oriented languages like C#, but we are going for the ultimate benefit for the project, and not for the abstract beauty and purity of principles).

What else can be cut in the project to make the project cheaper:

  • remove testing, make it superficial
  • remove code revision
  • remove code refactoring (i.e. gradual improvement)
  • remove application and server diagnostics
  • replace some complex parts of the application with simpler ones, for example, chat with static correspondence.

Deadlines prolongation

If the programmer works in the state, then it is profitable for him to pull. If he works piecework, then there is no special point in this.

But it happens that the team has a lot of projects. I don't want to miss new incoming projects, and there are still old ones that also require attention. So there is such a situation that developers are pulling the rubber to introduce some innovations into your project.

What can I say in our defense (as a representative of the developers' side)?

Taking projects with a margin is not the greed of developers, it is a vital necessity. Some projects suddenly come to an end, some do not need to finalize anything now, somewhere a business analyst has gone on vacation and the project is on pause, in some project there is a delay in payment.

All this creates brakes in the movement of projects. And programmers need to be constantly given work, they can't just say, "There's nothing today, come back tomorrow." And it's not that we are so sensitive, but that a person will simply go to look for work elsewhere. It is extremely important for any studio to have a certain buffer stock for loading.

By the way, in our case, our solutions also act as such an additional buffer. If someone does not have enough downloads, we put on bugs in solutions or polishing some functions.

How can the customer reduce the extension of deadlines to a minimum?

  1. Reward for quick results. You can try to additionally encourage the development team to do faster. The main thing is to formulate clear conditions.
  2. To talk and agree on the main intermediate points for controlling the situation.
  3. Prescribe your wishes in as much detail as possible and remove everything unnecessary. The big problem is often that the customer starts shoving everything into the project, which slows down the project as a whole. Ideally, the project should collect a key basis, start, and then - gradual polishing. But in practice, it usually turns out the opposite - we fatten the fat cat (I mean the project) to such a state that the customer can no longer think of what he needs to implement and only then, after a long time, the project is put into operation.


I really hope that such tricks and tricks from programmers will not often occur in your practice. In any case, now you can recognize them and process them correctly.

Let 's repeat them briefly:

  • reducing costs by cutting off some types of work;
  • offering new technologies;
  • "crutches" in the code;
  • not clear technical task;
  • unnecessary functionality in the technical task;
  • hiding future problems;
  • binding to yourself;
  • deadlines prolongation.

P.S. We recommend you to see our article How to choose a programmer

If you liked the article, then please like, subscribe donat, … please share it on social networks.

Насколько полезной была статья?
Falcon Space, автор блога

The author of the article is Ruslan Ryanov

The creator of the Falcon Space platform

Watch demo

Product marketplace Service platform Rental site CRM for B2B CRM for cargo transportation
Demo solutions can be developed and cardinally business logic for your subject area
 Demo of ready-made solutions

How do I know the budget / timeline for my project?

1. Create a project concept

Concept Template

2. Send us your concept paper

to Whatsapp +7 920 954 2217

3. We will prepare a commercial proposal with details by modules

KP example

Falcon Space Platform

This is a reduction in the cost of ownership

at the expense of fewer people to support

This is a quick change

while using the program

This is a modern interface

full adaptation for mobile devices

Component demo stand
At the stand you can see various components in action - tables, forms, modal windows, diagrams, a map, etc.
Solution demo site
Basic solutions that can be flexibly adapted for yourself - change the appearance, business logic and even the structure of the database.
Discuss the project
Ask the initial questions about the project that concern you right now. We will advise you for free and recommend the best solution.

If you like our articles, then please subscribe to our channel in Telegram - Falcon Space.
In it we will publish updates on articles and other materials regarding our platform.