Imagine that you run an online service company and you do some service for people and your business becomes so big that your departments no longer fit in entire floors of a big building and your budget is so big, that you don’t give a damn of caring about people and raising their salaries, because you can hire someone else of the same level the next day. Well, in fact you don’t give a damn of people’s level at all, because they write throw-away code anyways and they do jobs that can be trained for in no time anyways.

And you don’t care about code quality, because it sort of “does not sell” and not measurable. And one day an irritated software engineer adds some poorly-written code to some function, that might not be important at all, because he is sort of a grunt programmer anyways and can be replaced and he knows that, because you made him know that, because you don’t want him to be too ambitious anyways. And he does that, because he needs to fulfil some nonsensical deadlines, that are made to create an illusion of control, because the boss hardly understands what this guy is doing, but it sort of needed anyways, because the boss needs to get salary after all.

Now it turns out, as usual, that a more important function depends on this function through a long chain of dependency, that might even span across systems, and one day an unlikely situation happens and the function fails, leaving the database partly consistent, because all the teams work in this style after all, so they don’t verify consistency of each others output anyways.

And one day a customer presses a button on your website and a record is inserted into a database twice, while notifying the customer only once and his credit card is charged twice.

An the customer calls customer support, but the customer support employee has no way of sorting out database inconsistency anyways and she is not allowed to talk to programmers, because it’s prohibited by the policy anyways. So, she queries the customer for information and sees that it is inconsistent and she is not allowed to deal with the customers that provide inconsistent data anyways, because they might be fraudsters.

An she tells the customer that he is lying and passes the buck and an angry message appears about the company on a complaint website. An the quality control and legal go after the customer and trying to pull the details out of him, but he sends them away, because he does not want to deal with this stupidity anyways.

But who cares if the cash flows?

In our days all paperwork is being digitized extremely rapidly. Businesses abandon old ways of communicating with customers, and this puts more and more responsibility on computer systems. However, computer systems are not owned by customers and if they are designed and developed and such way, god knows what can come out of it.

Transaction processing is not a trivial thing. It takes some effort to understand concurrency, read consistency, multiphase locking, physical consistency and so on. 40 years ago a group of people at a very well known company teamed up to solve this kind of problems and came up with beautiful solutions that was focused on mostly one thing: making sure that when deducted from one account funds appear on another account or nothing happens at all.

Also, when it comes to communicating with customers in an automated way, certain degree of human-computer interaction science must be applied, otherwise the customer might not be able to react adequately.

Understanding of these things and many others and using them properly and wisely puts enormous responsibility on the smallest guy — the software developer. And believe me, you have no objective measure of his effort. In fact, he or she needs to constantly apply love, care, skills and wisdom and order to put the right things into that function.

This creates a principal-agent problem: you don’t know if a software developer wants to make the code better because he wants more money or because he wants your software to function better. It’s worth reading the article to see how to approach this problem.

However, this post is not about making my job look important, this post is about the fact, that as an engineer I’d stay away from using a system, that is designed and developed with less prudence, especially if it deals with my money.

But the challenge is that in order to develop such systems, software developers have to be trusted, such as when we trust doctors, when they deal with our health. And this is a hard thing to do, especially if programmers look like punks and the principals have little understanding of computer science.

That’s why issues like the one happened with the function continue to proliferate until the value of qualitative programming will be fully understood.