Software development is to redefine and solve current problems in a virtual space, and most of the time there is no right answer. How to traverse these uncertainties and unknowns reflects the developer's skill and grasp of things .

In the past development and consulting careers, I have worked with many different people, and positive discussions are certainly there, but there are often cases where the discussions only make things more vague. In some of these situations, after reviewing the situation, I feel that the other party did it on purpose, and it may even come from a strange mentality of wanting to show off.

The title is a bit provocative, but this short article records a few possible practices that are relatively impressive, and after flying for a while, you find that you can't get any stanzas (?

So it's actually the other way around...

If you look up the definition of nonsense on WIKI, it is probably as follows

Nonsense , meaningless words. Nonsense refers to a piece of language that does not have any positive effect on the development of the situation at the time , or is logically contradictory. In addition, it also refers to a sound or sentence composed of words or symbols but does not have any meaning, or can refer to a person.

Of course, it is a bit arbitrary to directly classify these unhelpful words as nonsense. What I want to express is that the premise of effective discussion and communication must be based on a consistent background understanding and goal . If it cannot be truly converged, the result may not be too far from nonsense.

Here are three frequently encountered situations to share with you

1. "There's something wrong with your architecture!"

This sentence is really a big killer, and it works well with the unpredictable expression. People who hear it usually examine themselves first. If you are not experienced enough, you may even fall directly into the quagmire of self-censorship (and then the more you think about it, the more reasonable it becomes...).

After all, where is a 100% perfect system architecture? If there is such a perfect solution, the system will gradually become imperfect as the dividends brought by the successful architecture. For example, the classic C10K problem occurs after a certain business success.

Real-world development is a composite result of business models, domain knowledge, development techniques, cost planning, and process management . If the sentence "There is a problem with your architecture" is true, it actually only describes a result. What is important is to split the problem in more detail.

2. Talk more about ideas and not about trade-offs

"You have to write a complete test and then develop it!" "Your abstraction layer is not clear enough?" "How far is your information security?" "Will the performance be affected?"...

I don't know if you will hear these words often.

These are all good ideas, but to be honest, overemphasis tends to obscure real problems—such as lack of time or resources. Too much information of this type will often fall into the situation of talking about each other, and in the end, it may just explain what you care about rather than what is helpful to solve the current problem .

There is a saying that goes well, "The result that everyone is dissatisfied with is the best result". The same is true for system development, which is more often a compromise than a battle of ideas .

3. Focus on less likely scenarios to show your integrity

After the development of today's software systems, the changes in the external environment are often beyond imagination. Any unanticipated situation can cause problems.

You have always encountered users who do not update their phones, right? Do these bugs (?) need to be fixed?

In fact , the correct operation of the system is the result of cooperation between the environment, the operator and the software itself . Or we can say that the error occurred because one of the three did not perform his duties properly . If viewed from this perspective, and a concept similar to "contract" is introduced to understand the system, these so-called bugs are more likely to be known unknowns .

And that's not to say we can't deal with exceptions, but again, overemphasis is a hypertranslation that ignores practical considerations.

Of course this might make you look smart (?

Summary: Time is limited, but problems are endless

The discussion of system development has its charm: on the one hand, it is engineering and natural science, backed by logical rigor, and on the other hand, it blends some softer (even related to social science) open issues. It is often discussed that later, I don't know whether it is in "Ke Ge Yan Erzhi" or is really focused and convergent.

As an engineering developer, our goals are often clear, but the content is uncertain. After all, our time is limited, but the problems we face are endless. Going through those ineffective dialogues and words can save waste.

What kind of nonsense have you heard?