Developer Diary or Bad Decisions
From tomorrow we begin to live in a new way. We will have Scrum and there will be happiness. Full democracy: no bosses, the team decides for itself what to do, the bureaucracy is canceled, the main thing is to make the customer well.
The coach came and taught us the basics. He told about the inevitable success, about efficiency and customer focus, about the unprecedented flexibility and the importance of involving the client in the development process, and about the spacecraft plying the Bolshoi Theater.
Oh well. Wait and see.
We are starting a new project. Well, thank God!
And then I already covered with moss from sitting above the Legacy code. My strength is gone, I can not cope with this great macaroni monster. I somehow tried to move the button on the login form, so my errors from the mail module fell down. Think about where the connection is ...
They introduced us to a new employee, we will have a Product Owner or, in Russian, a customer representative. Name is Rita. Charming woman. He likes to talk very much.
Ask her a simple question, so she starts a speech for half an hour. You look at her and you think: “Eh, you don’t understand a damn thing!”.
Five minutes later, you begin to doubt: “No, it seems to be the case”.
In the end, you realize that you never received an answer to your question. So leave.
The main thing is to interrupt it is not possible. You try to drive in and direct the flow of words in the right direction, but where there, she knows herself to be flooded and tells again about the ships and the Bolshoi Theater.
We really began to be afraid to ask her even simple questions. You can get an answer, but you can drown in the ocean of words.
Yes, there is indeed less bureaucracy. Because everyone scored on documenting at all. Now the information is transmitted mainly from mouth to mouth. Of course, I understand everything, we are very agile, but not to the same extent ...
Given the task: to develop in the gateway the ability for the client to receive data for displaying the schedule. It is necessary to contact the service, get the raw data, recalculate them and give it to the client. There is no specification what and how to count - nobody knows. There is only the name of the schedule. Well, how should I do this, I wonder?
Okay, I found somewhere in our old projects something similar, I did it on the model. There is no certainty that this is what is needed, no. Strange, but nobody really cares. The main thing is that we have successfully presented new functionality at the demo rally.
I come to work today, there the girls-testers surrounded our scrum-master Kohl, and they demand to explain to them how the new functionality works. Kohl looks with tin eyes at the monitor and mumbles something about the models and about changing requirements.
Kohl can be understood: something was changed a month ago, but what exactly is difficult to remember, there is no documentation. But the girls are not sugar: they were instructed to test something, I do not know what.
I met them in the corridor in half an hour: Kolya paces, the girls follow him, and everyone makes noises: “The new model ... the old model ... customer requirements ...”.
I received a pull request for a review. Error in the export of graphics: the proportions of height and width are different from the original. Strange, because I once solved this problem and took care of all the proportions ... The problem was solved in an original way: a colleague simply multiplied the height by 1.25.
I ask him:
- What does this coefficient mean?
“And this,” he says, “I picked up.” Now everything will be fine.
In both! He picked up ... And what about the export of other charts? Began to understand, it turned out that you just need to slightly change the sequence of calls. In some very rare cases, your canvas settings are used, and the proportions should be recalculated after that.
It seems that sometimes it is important for people to report on the work done by any means, and the end result doesn’t really bother them ...
Today, Rita announced that she had decided to use endless scrolling when displaying a list of documents. I tried to convince her that the situation in the REST service is constantly changing: some users add documents, others delete. As a result, either unnecessary elements will appear in the form, or they will disappear, so it is better to use the good old pagination. To which I was answered that such a situation is rare, and endless scrolling is fashionable and sexy, users will be happy.
Satisfied? Hmm ... I would be upset if I found that the list does not match the current state ...
I don’t understand how to build a building of shit and sticks, without a foundation, starting at the same time from four corners at the same time. Sometimes I think that if planes, ships and skyscrapers were designed in the same way as modern software, the planes would immediately fall, the vessels would turn upside down, and our cities would lie in ruins. It is clear that we have the price error is much less. In the end, we do not create medical or space software. But our software is complex, uses many microservices. It is necessary to pay some attention to the preliminary study of the details!
It's good that we do not construct airplanes ...
He looked into the next department and from the threshold felt that something was wrong. Everyone is sitting, knocking furiously on the keyboards, and in the air there hangs some kind of general trouble.
Suddenly, their scram-master Vitya jumps up and as someone shouts:
- What do you write me everything! Say orally!
And then they burst. All at once shouted. Oral. The noise rose extraordinary.
I stood for a minute, coughed, everyone was silent and stared at me. I suddenly felt somehow uncomfortable.
- You have changed the authorization in the service?
- Yes, - I answer, - I have. Now users without rights cannot read the resource. We must use another way.
“You've changed,” he says, “and now the application has stopped working for us.”
He paused a little and added:
- You did everything right, this is our joint. But we, you know, need to roll out the release after three hours, and we can't fix the mistake so quickly.
I wanted to tell them: “Well, you devils, tests have never been launched, because the week has already passed!”, But looked at their faces, turned around and went to roll back in service.
Gathered us today the main and says:
- It would be necessary to start an epic. We want machine learning to enter to customize search results.
The people, of course, wondered what was meant and if there was a description of the problem.
- There is no complete description yet, I will give you a link to what is. Think for now - responds. And left.
I then looked at the page on his link: the title and two points. And how to think order, if it is not clear what to think?
What is happening with them, because the technical people were, from simple developers have risen, and now it seems that they have been reborn as clients. I heard somewhere that artificial intelligence is fashionable and cool, and let's start epics. Neither the task to specify, nor the specification to write the exact, all entirely high matter and spaceships with theaters ...
I meet Vitya today in the corridor and ask:
- Well, have you found a mistake? The month has already passed. It would be necessary to restore authorization in the service, and then we live with a hole.
Vitya looks away and says:
- No, we have not found it yet. There is not enough time at all ...
Well, you are welcome. For a month, people cannot find a place where the wrong endpoint is used. Apparently, they have already abandoned it and are engaged in current affairs. Strange, because the program, in fact, uses incorrect data ...
Yes, our new gateway has turned into a tight tangle of pasta, and it is already impossible to find the ends. Quickly we managed!
I am trying to convince my colleagues to talk to the authorities about the current state of affairs. From my point of view, the project is in a deplorable state: different teams, solving their problems, make edits that increase the chaos, the entropy grows. Each time, solving problems becomes more and more difficult.
The guys agree with me, but my initiatives are cool. And they can be understood: everyone has current tasks that must be solved during the sprint. There is no need for philosophizing, it is necessary to do something ...
I admit: I invented this diary. All characters are fictional, coincidences are random. This is just a joke.
It sometimes happens that the management perceives Agile somewhat vulgar: it is enough to describe the task slightly, and a good team will deal with all the architectural and conceptual problems itself. Often overlooked is the need for thorough documentation, although the use of Agile does not mean giving up documentation.
However, I wanted to talk not about Agile and not about development technologies. I want to speculate about the quality of the software that we are creating, and how bad decisions can destroy this software.
Conflict of interest
You are a developer. The project or part of the project you are working on is your favorite child. You create and nourish it, you want to make a perfect creation. So that your colleagues and users can say: “Yes, this is a cool thing!”.
But you work for the business that hired you. Business is not interested in your ambitions. The main goal of the business is profit, and rightly so. Here you are with the business at the same time, because you want more people to use your project?
But for one reason or another, a business can make decisions that disrupt the harmony of your project. Let's say you need to quickly tweak something, or the client will leave. No time to solve the problem correctly.
What to do?
Most likely, you will have to break yourself, hoping that the current crutches will be able to be removed later ...
However, not everything is so sad. In the long term, business is your ally in the fight for quality, if it is, of course, not your enemy.
Although we had to deal with such an approach that careful study of the details and analysis can sometimes be neglected, since quick and cheap customer satisfaction is most important. Is success possible in this case?
Is success possible?
The paradox is that such products may well be commercially successful, at least in the first stage. Of course, customers are annoyed by many flaws and inconsistencies in the system, but, in general, the product solves their problems.
Customers are satisfied with the level of support: they treat their needs carefully and try to quickly meet new needs. True, some of them over time notice that the system becomes more and more contradictory and unpredictable in behavior, the interface becomes more complicated, it becomes more difficult to understand what is happening inside, how to solve this or that problem correctly, problems appear with response time and so on. But this happens gradually and imperceptibly at first.
No one suspects that the project is doomed. Soon it will inevitably collapse from the severity of all the extensions stuck to it in haste.
How is the internal harmony of the product with its consumer qualities? It often happens that the developers are in a state of permanent horror from the internal state of the system, while the customers seem to be satisfied. But can an ugly plane be good? And shouldn't the inner harmony of a product reflect on its consumer qualities?
It is no secret that often obscene entrails are hidden behind a beautiful facade, and this applies not only to small firms, but also to the giants of the software industry. Here is just one example .
Monster companies can afford to hire thousands of programmers to support a giant dish of spaghetti, which their product has turned into over the years and decades, but for small companies this is a deadly path. And, by the way, even for monsters, the low quality of the code does not pass without leaving a trace and turns into an exponentially increasing time of development and implementation of each new feature, process appreciation and constantly decreasing quality of support.
What is more important: the quality of the product or the ability to sell?
A quality product, alas, is not the key to success.
I have had a case in practice, when one highly specialized program, which had a good reputation in Russia, had to be promoted to the European market. The program used its own data format, and converting existing customer data was not particularly difficult. If we could conclude contracts, we would become monopolists in Europe for a while. It would seem that everything is on our side: the demand on the market is large, nobody can offer something complete and really working so far, except us, the program is already working on hundreds of jobs in Russia, Russian customers speak positively about the product.
And what, we have achieved success? Unfortunately no. The tender was won by a European company that has already worked with clients in other areas. At that moment they were only at the beginning of the path, which we had already passed, but managed to outplay us. We, unfortunately, did not have good sales and promotion specialists, and we could not convince people to make a choice in favor of our company. Then, after some time, it was very disappointing to see our developments in the organization of the user interface in their new product ...
A quality product is a strategic goal, and smart business will always be on the side of a developer striving for perfection. But to maintain the internal harmony of the product is not easy. With the development of the product, new requirements come to us that can destroy the original symmetry of the concepts. The decisions that are made in this case play a decisive role in the future fate of the product.
No one is immune from bad decisions. If a strategic decision is made at the design stage, and over time it becomes clear that it was wrong, this leads to the death of the project. But often bad decisions are made during development, when new functionality is added. It all depends, firstly, on the globality of the decisions made, that is, the degree of their influence on the system as a whole, and secondly, on the number of bad decisions. When the number of bad decisions and the degree of their influence exceeds a certain threshold, a long and painful agony begins.
I would like to share with you a few examples of bad decisions from my own experience. Of course, these examples in no way pretend to be academic in breadth and systematization.
Sometimes it seems to us that, for the sake of user convenience, the rules should be flexible.
For example, your system works with different types of user-created hierarchies. You decide that for one of the types the node key is unique only within the level, and not throughout the hierarchy. This seems convenient since the user loads the hierarchy in levels.
Consequences: now programmers everywhere in the code will have to take care of preparing a composite key, and this will often lead to errors. If users have access to sites by key, this will also be a headache for them.
It may be worth thinking about stricter rules and requiring key uniqueness throughout the hierarchy. This will benefit both developers and users.
Breaking the rules
You have a complex hierarchy of user-created objects. Each object contains the Name property, which is a key, and a Title with arbitrary text. For the name there is a set of formal rules, for example, the name should not contain spaces and special characters. At some point, the problem arises of automatically generating objects of one type from another. The name should be based on the Title and be recognizable. You decide to break the rules and use Title as the name: it seems to you that this will be the most convenient for users.
Get ready for problems in your system that will arise in the most unexpected places.
Complexity of settings
You enter settings that are valid only under certain conditions. When some installations operate under the condition that others are included, this is quite a common situation. But if you have a complex hierarchy of attitudes, some of which operate when others are included, and those, in turn, are also conditional, is the path to chaos. Experience shows that in this case, no one is willing to predict how the change in one or another setting will affect the behavior: neither users nor developers. The system of settings should be clear, as obvious as possible and carefully thought out. You should strive to reduce the dependence of some settings on others.
No problem analysis
Your system allows the user to create reports based on DSL. It was decided first that the DSL contains all the properties of the report. After some time, one of the clients asks you to add the ability to store part of the installations separately - this is needed to solve some internal problems of the client. Setting a task in Jira “Add external settings” without first analyzing the problem will be an error. First of all, it is necessary to answer the question: why is it even needed? It may well be that the client simply wants to hide some of the installations for some users. Maybe it is worth thinking about splitting the DSL into parts with the authorization of these parts? The decision is not so quick, but perhaps strategically correct.
Sometimes decisions are made on organizational grounds. For example, certain resources are stored in a dedicated microservice. It is required to add several similar types of resources. One team is engaged in service, and new types of resources are needed by others. In order to share responsibility, it is decided to add new types not to the original service, but to services managed by other teams.
The problem is that the service not only stored data, but also provided authorization. Now you need to somehow take care of the reuse of the code. But this is not important. The main thing is that now it is not obvious what service should be used to obtain the necessary data. The internal evidence of building a system has been sacrificed for organizational or political reasons.
As a developer, I want to be proud of the results of my work. For me, the inner beauty, elegance and harmony of the project is important. But no less important and demand. I do not want to work on the basket, I want as many people as possible to use the product and be satisfied. I understand that sometimes you have to go to the costs and spoil the inner harmony a bit in favor of the interests of individual clients. But I am convinced that there should be no ugliness behind a beautiful facade, ugly insides will sooner or later come out, no matter if it is an external confusion in concepts, or an ever-increasing response time to customer problems.
The beauty and harmony of the product is most important. Yes, we sometimes have to make compromises in the interests of business and are ready for some blurring of clarity of approaches in the interests of a particular client, especially if it is a very important client, but it is a slippery slope.
I have often witnessed the gradual extinction and death of projects, when people did not bother to thoroughly work out the details and thoughtlessly introduce new functionality without worrying about the emerging contradictions in the product and not paying attention to the emergence of new and unnecessary links between modules. This always leads to confusion when it becomes harder and harder to correct the simplest mistake, because there is no certainty that this fix will not have an unexpected effect on completely extraneous components and parts of the system.
I want to wish a long life for your projects!